Premature Generalization is the Root of All Evil

Finally! I have now finished the first reincarnation of the new logger hierarchy for Microlog. It is a very simple tree structure that keeps track of all the created Logger objects. I choose to do a specialized tree implementation for the purpose, not a general tree implementation. Since there is no tree implementation in Java ME, it could be tempting to do a tree implementation for Java ME. When finished this could be re-used in a lot of other Java ME projects. This got me thinking about those good old days when I was a junior programmer, just fresh out of school.

I was involved in a research project with the purpose of showing the opportunities with an embedded device with an ethernet connection. The embedded device contained a simple web server that was equipped with simple CGI support. My assignment was to create a web pageswith a Java applet for administration of the embedded device. This was actually a proof of concept study. If we managed to convince our product managers about our genius invention, we would of course re-use the code for the real product. So far, so good.

I made a very ambitious design before even starting to do some coding. I can tell you, my manager was really nervous when I did not start code immediately. "No worries, good design is important for fast and good implementation. You need to be prepared really good before starting your implementation!". This was how I was taught. Anyway I managed to do a real fancy design, with many really nice-to-have-classes. I ruled the world of design and my way to fame and glory was laid out for me! As part of the design I did a very general API for the communication. General design is good, I reasoned. This was a BIG mistake!

When we were closing in on delivery date for the demonstration, I had made the general network communication. However I was not finished with real implementation, the parts that was vital for the demonstration. Anyway I was finished about 30 minutes before my project manager was going to leave for the airport, to meet the people who was sponsoring our research. I was tired since I have worked all night and my project manager was not happy. For me it was embarrassing that I was not able to deliver something that I was proud of and I was to close to the deadline. My project manager did manage to do a successful demonstration. Finally the management decided to make our prototype into a real product.

After a couple of weeks it was decided that we was going to use another low level protocol for the communication. It turned out that my general design was useless, since I did not anticipate all the aspect of the problem. But what did I learn from this rather embarrassing moment of my life as developer?

First of all I realized that I do not have the powers, like Nostradamus, to see into the future. I also came to the conclusion that you have to know the domain, before making any generalization. You have to do your first implementation in that domain, before you should make any general design. When you continue to evolve your product, you can figure out what parts of the code that is reasonable to generalize.

So I invented a rule that is "Premature generalization is the root of all evil design". It is of course inspired by "Premature optimization is the root of all evil". Nonetheless I think it is a good rule. This is why I choose to do a specialized tree structure for Microlog, instead of making a more general tree implementation. I have seen the phenomena of "premature generalization" in many projects since. For some reason it tends to be junior developers who fancies these general designs. Today many more people learns design patterns, than when I finished school. There is a big risk that you use to many design patterns, without really understanding the consequences. I prefer to get the code working and to deliver it in time for the demonstration. When adopting my golden rule stated above, this is not a problem. Thanks to agile methods, like Scrum, you are forced to make your application ready for demonstration early on. But that is another story.

Öredev 2008: Agile, Scrum & Boom Chicago

The 2nd day of Öredev was very long and thrilling. As a change I attended a lot of non-technical sessions. The first session was called "Scrum @ Yahoo" held by Gabrielle Benefield. She presented her own story about the introduction of Scrum within Yahoo. The story was presented in a funny and intense way. One thing that struck me was that the managers was afraid to loose their jobs when introducing Scrum. As she pointed out correctly; Scrum is very developer centric. For some reason I have never done this reflection. The same concern was also raised by Allan Kelly. But they seemed to have the same opinion; the managers should not be afraid of loosing their jobs. The most funny slide from Gabrielles session was the one above. This tells a lot about the power of Scrum.

During the day I had the privilege to meet up with Terrence Barr in person. He is a Sun Evangelist and Ambassador for the Mobile and Embedded Community. We had some interesting discussions about Microlog, the Mobile and Embedded Community and about the Java ME Open Source community in general.

We ended of the evening with some refreshing drinks and snacks. The improvisation group Boom Chicago entertained us with an funny interactive show. After the show I was pretty tired and got home rather early.

Here are the rest of the photos from day 2 at Öredev 2008:


Terrence Barr and me at the Öredev entrance.

Learn the Scrum way from Gabrielle Benefields presentation. Note; this is not the way Scrum should be introduced.

The keynote speaker of the 2nd day; James Bach.

James Bach showing a photo of where his laptop last was seen, namely the the central station in Stockholm, Sweden. He was a little bit disappointed that there was no swedish polices at the station on a Sunday afternoon.

The Boom Chicago group entertaining us.

"Mick Jagger" and "Amy Winehouse".