Self training

In a world, where because of the globalization, there are people that don’t get a very good night sleep, the quest for efficiency is more acute then ever. In the world of software development, efficiency can be gained by two primary factors:
-reuse
-improve your developers

If for the primary, the best answer lies in front of you and comes from Microsoft, (just think about why IE couldn’t be removed for good from Windows), for the second there is still no clear and single answer.

Short “knowledge spreading” meetings

One way to improve the knowledge level, that proved very useful to us, is to have short meetings where different things, from pure technical to methodology practices, are discussed in front of a whiteboard. Agile teams, where everyone has something to offer, make this technique very beneficial, as combined with osmotic communication (See Alistair Cocburn's Crystal Clear), it is a great way to spread knowledge. When doing this kind of meetings, from the experience we have, there are a few things that need to be taken into consideration:
- meetings must have a plan of what will be discussed
- meetings must be short
- everyone can propose subjects to be discussed
- everyone has to be involved
- have a whiteboard
- make sure you really have something to talk about (ideally probably you should have one meeting every week, not less)

In any agile team, open communication must be encouraged at the maximum. This is one very good technique of doing it.

School like sessions

One problem I noticed after adopting a new technology (NHibernate – http://nhibernate.sf.net – some of us were familiar with it or other ORMs), and using it in several small web projects, was that although it was used for quite a while (two months) it was misused, as not too many things about its possibilities were known. I also felt as if with each new project and team adopting this new technology, the knowledge was weaker and all misusages from the early projects were propagated to the others. We even got to a point where a colleague told us that he doesn’t really like using it and we saw that he was reusing some badly written pieces of database layer code, from earlier projects. I saw then that the problems were not with the technology but with lack of knowledge about it.

The reason for this might be time pressure (I don’t really buy this one) or , a more plausible one, that the developers of the second project took the code from the developers that developed the first one, as “good”, as a reference of how thing with NH should be done, trusting the first team and reusing the “misused” code.

Then I decided that it is time for a new meeting looking trough the code one day, but then it stuck me: how about making a school like activity, where everyone reads about a thing, then have a small test to see what the understood from it, and if the level of understanding isn’t satisfactory re-explain everything. Said and done. I decided that at first I should make a small introduction about the most basic things in the technology for the people that haven’t used it yet, then give everyone an article/book chapter that seems very relevant when you want to explain a new technology, going deep into it, then after the reading session is over, everyone gets questionnaire, and sends back the answer to see if they understood correctly what was needed, and if they really found the hot spots in the material. After analyzing the answers, from everyone, all the answers were discussed with everyone in front of the whiteboard, to make sure that everyone understands what needs to be understood.

Is it worth it?

The results were very pleasing. For two reasons: everyone after only a short time had a good understanding of the new technology (transient/persistent/detached states, moving an object from one to another, hql, criteria api, eager/lazy fetching, associations etc) and since it is not a requirement to memorize everything , at least, when confronting a problem, the developers will know where to look for, they will have a good image of the documentation, and where to look for specific answers. I strongly believe that even if that this meeting can take a couple of hours, this time is very quickly recovered by having people know what they do and have less bugs and problems the kind we has with misusage.


Another very interesting fact, was that after two such sessions, everyone felt very happy, knowing something new, or some intimate details, making them more motivated and more keen to start working with it. It made developers happy. Remember my article about sharing the thrills?

The knowledge wiki

At the suggestion of a dear friend (which can be found in the comments), we installed a wiki. Actually it is not a wiki, but an simple CMS system, developed internally, where people can share information, and where information has something that is lacked in the first two approaches: persistence. A wiki, has the main purpose in my opinion to keep the links where people can read more, a common place for links, a common 'favourites' system and also, and most importantly, a place where the hard to find information can be shared and persisted, information like, bugs and false assumptions about new technologies, samples for different internally developed technologies or other deep things.

Whether this will be a sucess or not we will definately see, but although the system has been installed, just for a few hours, it seems to be a success, as everyone seems very interested in both reading and writing content on our wiki, and even suggestions about extending it with a forum appeared.

Some screenshots can be found at:
Wiki and Administration

I certainly hope that besides this techniques, there are others that wait to be discovered in our big goal of become better, by self training and better knowledge sharing, and that this discussion does not end here ...