Posts

by on

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.

by on

In the movie Soldier, the soldiers are humans selected at birth and conditioned to obey orders and win battles. The antagonist comes up with genetically engineered super soldiers who are better in every single metric like long runs, fast climbs, weight lifting and many more. As a final test the protagonist is put up for a fight against a genetically engineered soldier, loses the combat. He is thrown away into another planet  along with the trash and two others who died in the combat against the mutant soldiers. He ends up in a new planet and gets taken care by the people there. The antagonist tests the mutants’ battle skills at the new planet, which brings them to fight against the hero who kills them all in a real battle field scenario and takes over the ship.

Metrics of software development and developers if not used at the right level, will start giving us an illusion on control. They are more like a guideline which can hint at the presence of a problem rather than an assertion of well being. In agile projects velocity is one metric which is very visible to the client, what was once to help in planning becomes an important metric in presentations; so are cycle times, bugs per story, lines of code etc. The illusion created by strictly following all metrics taking actions based only on that will lead to two problems.

  • It will encourage work to be based on the metrics, like legally right but wrong in principle.
  • It will shift focus away from mainstream work resulting in loss/delay of work.
As far as I have observed, when metrics are limited as tools for diagnoses and planning they have helped a lot improve the progress by allowing the individuals to reflect and retrospect; take small corrective steps. When a single person takes a strong corrective actions on the course of the project based on the metrics then success was a stretch goal.

Image: Michelle Meiklejohn / FreeDigitalPhotos.net

by on
  • Work never stops coming to you everyday, forces visibility into everyday’s work.
  • Deployment to production is too easy and predictable, no chance of heroism.
  • No one person holds the information, every one knows every thing; no one is indispensable.
  • Complexities are sorted out earlier, it is difficult to get into a messy situation and raise like phoenix from the ashes.
  • Creates self managed teams, making the lead positions redundant unless hands on.
  • Makes you assess, try and embrace new technologies; prevents you from becoming an expert in Z platform.