Thursday, May 05, 2005

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:
-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 – – 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 ...


somalezu said...
This comment has been removed by a blog administrator.
somalezu said...

Very well said, Dan. Introducing a new technology to a team it's a sensible task. It is more difficult to do it right if the team is already used to some other equivalent technology for some time – it’s much difficult because you must change the way people think. (After all, it’s harder to learn an old dog new tricks  ).
I got one suggestion for you: we use a wiki like a central reference point for our team. From the day one, when some member of the team is evaluating the benefits of some new technology to our project, a wiki page (or topic) is opened on our internal server. The people involved in the research are encouraged to write an article (or presentation of the technology) on that wiki, insisting on the needs and the benefits we all could gain adopting it. Nothing too formal – but explicit. The wiki gets content pretty quick about tips and tricks and a lot of references to interesting material that should be consulted. If the new technology is adopted, the whole team must read the wiki and should post any questions there.
It’s a little more difficult to put a wiki in place of the team meetings – it’s surely much harder to write than to speak.... But there are some advantages – first of all, the wiki remains a reference point for all the activity on that mater, from now on. New questions, tips and tricks and hot spots will be added on day by day bases. In other words, the discussion doesn’t end with the meeting. It’s kept alive, and it is available for all the team’s members. (That’s why I encourage using email notifications of the wiki page changes).
We use that system for vary small teams and it seems to be pretty damn useful. I even use to read my own contributions I wrote there some months ago every time I need to remember why is better to use some special technique and not another, or when I am looking for some example of things I done already. And the wiki is an excellent start point for new members of our team or members that should lear that technology. We even use the wiki like a team favorites folder, to store links to useful materials or cool places (it is surely more usable than the IE’s favorites menu, because it can accommodate comments and it could be accessed from different machines – from office and from home for example).
Probably the best way to solve your problem is to combine these two approaches – writing the wiki from the first day the research guy has contact with some new technology and doing the meeting when the time comes for the whole team to adopt the new technology.
Best regards,

Dan Bunea said...

Hi, it seems that together we make a hell of a team :)

I am a strong beliver in direct communication, speakig as the best way to exchange information. However as you pointed very well, this infromation, lacks persistence, so having both the meetings and a info content management system or a wiki, probably is a killer combination.

Thank you very much for your contribution, and with your permission I will install a wiki myself so we can use this kind of aproach also,