by on

Most of the projects we start from scratch; we usually start with a build time of less than 2 minutes with all the unit tests, code analysis metrics and reports. If you have heard about the parable of the boiling frog, then something similar happens over the course of few months when the code has gradually grown in a large size and increasing the build time with it. My observation in one of the teams few years ago was that we got used to build taking longer and which was considered more of a break from an hour or two of coding. What we did not realize was that subconsciously we were aware that the build is taking longer and hence we accumulated a large piece of code before checking instead of smaller chunks. This had an observable problem that there were build breaks just before we were heading home and developers sometimes take good amount of time merging code before checking in.

XKCD compile time

It was not until we reached a tipping point that the entire team realized that the build time has risen to a point where it hampers a smooth churn of development. To our surprise it was only few hours effort to get the build to under 4 minutes from 12-14 minutes. From there on some of us keep a conscious watch on the build times and have a 5 minute unwritten blanket rule to jump on fixing it before it grows too large. Usually the problem was a monolithic code base which keeps the build time too high. Some frameworks like GWT will compile JavaScript for all browsers which might not be required to be done for every build. Making use of the multiple cores now available so widely is also an option to consider. Ramdisk is also another option.

The lesser the build time, the more it encourages us to check in code often which reduces merge conflicts; eventually leading to a mature continuous integration. A mature continuous integration ensure reliable and effective delivery.

by on

In the movie matrix Agent Smith says to Neo “But I believe that, as a species, human beings define their reality through misery and suffering. The perfect world was a dream that your primitive cerebrum kept trying to wake up from. Which is why the Matrix was redesigned” as an answer to why an Utopian matrix was a disaster.  So many inventions which have been dreams to our ancestors are now an indispensable everyday need in our life. Right now an individual with an average income is able afford phones, computers, automobiles and so on which was not so easy to possess just a few decades ago. Yet we crave for better ones and we keep getting them.

Countries where first civilizations surfaced and lived a life ahead of its times were later colonized by more technologically advanced nations which sometimes were much smaller in area and people count. If the civilization stops advancing then it is destroyed or taken over by an advanced one.

There has to be a constant urge to keep pushing ourselves to improve, upgrade and innovate else it is very easy for us to be pushed out of existence. The fact does not apply only to civilizations, it is for individuals or organizations as well. The pay check after easy days at office gives a false sense of security as it takes care of immediate and long term basic needs. Jobs are easy if there is not a slight stretch or push; a stretch or push means we are out of the comfort zone learning and unlearning, if we are learning and applying then we are advancing. If we advance then dreams become true through inventions and they become necessity.

As the advancements in technology and methodologies keep going sky high, the amount of preparation an individual goes through before landing at the workplace is also increasing. That puts a greater emphasis on effective and efficient learning right from childhood that will keep going on and on and on. Workplace always has a cycle of tight work, vacation and lean days, we can plan our continuous learning such that we don’t get burnt out and at the same time we are not left behind.

Every morning in Africa, a deer wakes up. It knows it must outrun the fastest lion or it will be killed. Every morning in Africa, a lion wakes up. It knows it must run faster than the slowest deer, or it will starve. It doesn’t matter whether you’re a lion or deer – when the sun comes up, you’d better be running.

Image: digitalart / FreeDigitalPhotos.net

by on

Every time I find it difficult to think of a good test to start, I am always tempted to try backdoors like getters, setters to help get started. The backdoors are not limited to getters and setters alone. Here is a list of my observations which has been used only for writing unit tests in Java easier.

  • Getters/Setters
  • Constructors
  • Equals implementation
  • Protected or package private access specifiers for variables and methods
  • ToString implementation
  • Special backdoor methods to alter the state of an object (The worst of all)

Any line of code which exists other than for another production code, it encourages a programmer in the future to exploit that backdoor for quick gains. As the tests are the specification to the production software, it is better to resist the tempation to use any of these. It also causes increase in code length and also an excuse for more people to follow the same path. The more time and effort I had spent trying to avoid backdoors, I have benefitted with more clarity in design. The benefits have prompted me to have routine static checks in the code base to keep them at check.

A question and a counter argument posed by a peer who belonged to another school of thought. If tests are considered to be first class consumers of production code, then is it right to have some backdoors help ease writing tests faster? Comments?