X-mas Present for Beta Geeks: new eZ components released

Here’s your early x-mas present: the eZ components beta2 are out! Seems like our developers had a lot of fun working on this release – that’s the impression I get from Toby‘s article and blog entry. When studying the changelog, it becomes clear that they put quite some effort into making this release useful for early adopters.

It makes me extremely happy to see the good development of the eZ components, as this is state-of-the-art PHP 5 development – right what is needed to showcase PHP’s OO-power. Now that the inline docs are available online, the clean design and implementation becomes obvious.

If you love to live cutting edge with PHP 5, check out the components and work with them. There are also Powered by eZ components logos available if you want to show off as a beta geek 🙂

Oh yes, and there’s #ezcomponents on irc.freenode.net now!

Mailinglists and Project Management

Mailinglists are quite useful as a part of daily project management. The way I use them at work is that I post rough ideas to the relevant internal mailinglist. Then my colleagues contribute with their ideas, comments and critique.

If the outcome of all the discussion is that we agree on actions and I am the one in charge to do and/or manage the implementation, then I simply group all emails in my Thunderbird inbox by the subject of the mailinglist discussion. This allows me to extract tasks from the discussions, which I store in the task tracker.

Now, I can keep track of every single issue by assigning each task to a category, giving it a priority, defining a due date, etc. Certain tasks might require some more discussion or consulting with other team members, which is done in the relevant mailinglists again – and this is where the process starts again.

In a nutshell, the approach is:

  1. Post an idea to the mailinglist.
  2. Keep the discussion going until a decision for or against actions has been reached.
  3. Extract tasks from the discussion.
  4. Discuss single tasks in the mailinglist if necessary (go to 1.)

Communication Skills

This seems to be quite simple and obvious, but in fact requires some sensitivity. The inital idea you post to the mailinglist, or the single task you want to discuss in more details, needs to be focused – otherwise you will end up with broad discussions that have no or too many results.

Then again, even a focused initial posting can lead to general questions. Either you moderate the discussion to become focused again, or you take up the raised issues because they might be critical, e.g. being a showstopper, or unclear responsibilities, or being of higher strategic importance.

As you are the one who raised the initial issue in the mailinglist, you should always feel responsible for the thread to be of value to others. Then you will automatically only post stuff which is important. On the other side, you can well invite others to help you become clear about certain problems if you got stuck.

Exchange of Information

Mailinglists are an excellent mean to distribute information within a team or even accross teams. In an ideal situation, they help to find solutions and make decisions jointly, something that fosters the support by each team member to actually implement his tasks.

The problem lies in a potential information overload, that too many people discuss too many issues in a mailinglist. The best way to avoid the overload is to apply the above mentioned communication skills.

As “overload” is also a subjective impression, it can help to learn how to quickly scan emails without reading them in details, to first spot whether they are actually of interest to me. The more subscribers are able to apply this skill, the more quality the conversation will get, as irrelevant postings will not get attention.

If in doubt, it is always better to have communication, even if too fuzzy and too much, instead of cutting it off. The question is how to canalize it in a productive way.

Other Channels

Of course, you can also apply the above said to other communication channels, e.g. forums or IRC chat. They all have their own characteristics though. A forum servers like a knowledge base automatically, similar to a mailinglist archive. Quite different compared to mailinglists, forums are not a push medium, but rather a pull medium, because you don’t get the information automatically to your email client’s inbox.

Open Company Culture

Using mailinglists as a part of project management requires an open company culture to be of benefit. This includes team members who are not afraid of telling their opinion with the risk to be challenged by others. In other words, they need to be adaptive.

In the end, being adaptive is the key of successful communication when implementing a project. Just remember that as a little baby, you were basically only able to screem. Today you can read (I asume so, because you read this blog) – and there’s always more room for the improvement of your communication skills. The main problem seems to be though, that most of us don’t remember the times when they were a baby and think that they’ve been born with ready-made communication skills 🙂

Codified Personality

In Knowledge Management, there are the concepts of codified and personalized knowledge. Wikipedia describes it as

codification vs. personalization – the trade-off between capture and storage of explicit information and making connections to people who know.

This definition was missing the fact that personalization also refers to making external knowledge part of your knowledge, thus I added “as well as to acquire external knowledge yourself” to the Wikipedia page.

Anyway, what I wanted to say is, that it struck me again some days ago, how nicely the personality of one person or a whole group can show up in software. The way how a routine or API is designed can tell a lot about the personality of a programmer and his team:

  • How accurate is the code? (You can tell from that whether they do a wholehearted job and are commited to what they do)
  • How much abstraction is in the code? (Reflects the experience of the developers)
  • How much is the overall design of the software thought through? (A criteria for how well the team can organise itself)
  • How complex is the software? (A sign for a team that can master software by organisational maturity)

This is what you can call “codified personality” – it is what you can also find in arts, in books, paintings, music, etc. Thus, the “vs.” in Wikipedia’s definition of “codification vs. personalization” is not totally correct, because the two concepts are not only opposed to each other, but can also go together nicely.

Of course, it is only a small step from here to ask: If personality is immanent in code, can code change the personality? Strictly speaking, code cannot change a personality, but as code is always the result of humans, it is the social system that those humans live in, which influences their personality. It is not the code that changes the personality of a person or group, but rather the way how the code is treated within the social system you belong to. As software code is codified personality, this is indirectly about how your social environment treats you.

Think of open source and proprietary as social (sub-) systems, and you’re encountering another interesting question: How do software licenses, as part of the regulatory system of your company, influence your personality?

Opinion and Authority

In a company based on hierarchical authority, it is much easier to have a strong opinion when you’re on a high level of the food chain. If you’re on a lower level, the problem is that you might be wrong or that your honest opinion might be something your boss does not want to hear. Thus, you act in an opportunist way and only say what’s mainstream in your company.

Knowledge companies cannot afford to have this kind of behaviour, they need everyone to have a clear opinion. Or put it like this: knowledge companies need to provide the freedom to their employees to have or form their own opinion and communicate it within the company.

An egalitarian organizational structure and predictable working conditions are thus a prerequisite for a successful knowledge company. They cannot afford to have the management rule by verdicts and fear. Instead, it needs to be trust and mutual respect, what drives the management to motivate the staff.
The more quality the opinions have, the better the decision-making within the company, and the more it can act realistically in the market.

lots.ch got kidnapped and misused to advertise a Company

Seems like the lots.ch domain got kidnapped. LOTS, that was a nice Open Source event in Switzerland, now its domain points to a Swiss company that does not even provide Open Source software. Poor LOTS got misused!

What happened? Well, LOTS does not exist anymore, the organisation behind the event ceased to exist. I don’t understand why they did not keep the Website as an archive? So many other sites link there, like mine, because I did presentations at both events in 2005 and 2004.

Chregu’s asking, whether the company tries to get some link-love? Andreas mentions that there were some problems between the LOTS organisers.

Anyway, I urge the company to make the lots.ch Web site available again or let the domain point to nowhere – but not to the company Web site – this is very bad style! And it harms the good intentions that LOTS had …