Malcolm Gladwell’s talk on Norden Bombsight shows how anyone can get obsessed with technology and accuracy but miss achieving the objective. The bombsight was invented to accurately drop the bomb on target so that lesser amount of people are killed and war comes to end quicker. The military spent a lot of money to develop and use it, and went to the extent of using the technology even to bomb hiroshima where accuracy was not necessary due to the destructive power. Wars lasted longer and the objective (bring the war to end with less loss of life) of bombsight was never achieved even though billions were spent on its development.

Software technology choices are similar, there are lots of new tools and many platforms that help us rapidly develop applications. The obsession to use the latest, cutting edge technology is so great that people take pride in showcasing their tool list once the project is delivered. The illusion created by the power of the tools is such that it gives a sense of great ability that we will be able to translate any requirement from the client into software in no time. Someone somewhere said that the computer can speed up the errors committed by humans, it is true especially when we concentrate on technology and automation more and more into every day’s work with less and less effort to question the requirements.

Subconsciously every one is concentrating on getting things done. Definition of done is often not put in the right way, if success of the software project in every one’s mind is to release before New year then people the actions and choices will be purely on getting out before New year. The emphasis on getting the project out faster would have eventually masked why the software was needed in the first place. Information technology which is supposed to help process information might merely be helpful in creating data capture tools because no technology can effectively capture requirements, anything which is captured often end up being lost in the translation.

Getting the definition of done right involves people in every discipline to work closely together. A project’s definition of done would be to help each individual get more work done with less exertion through the new software but instead of defining that the business owner might give a laundry list of things for the developers. A wannabe marathon runner training for strong legs is different from training for marathon runs. Training for strong legs alone will not help in running a marathon but it is one of the by-product of marathon training. Often requirements are just by-products or snapshots of a what an end product is going to be in a complex system. As far as I have observed successful developers are the ones who get as much information as possible about the system and put in an equal effort in getting a working software out without translation loss.

A helpful link given to me by one of the peers http://taotwit.posterous.com/vpec-t-a-thinking-framework-presented-to-scio

Image: jscreationzs / FreeDigitalPhotos.net

Working with Java has been almost inevitable for me. Many clients who have their projects written in Java and in the near future not going in for any rewrite will stick with them. Several Java frameworks and libraries have made heavy lifting simple and made software development more predictable and easy to code.

Some frameworks mandate the use of getters and setters to work with Java beans which make the code look bloated. It was also pointless to get these getters and setters covered in tests and they end up showing as uncovered. We have to configure to avoid these methods from showing up in the coverage metrics. Also the presence of getters tempts a developer to make use of it as a backdoor and get some quick fix done.

Lombok came to the rescue, with simple annotations it inserts the necessary getters, setters, constructors, equals, hashcode. These methods are added at the compile time which make the code look clean on the editor. Eclipse and Idea have plugins to support injected methods (Though it would be great if we do not rely on hand written code to make use of these generated methods. We should leave them only for the consumption of frameworks or libraries which demand getters and setters).

The other problem I routinely faced was the frequency at which we handle and manipulate collections. LambdaJ provides a pseudo functional way to work with collections. It makes the code very terse and when used in combination with Lombok on domain objects, Java code looks super neat with few hand written necessary methods while all the boiler plating is left to the compiler.

Lombok and LamdbaJ together will make working with Java code more coder friendly.