When developing in a highly matured business like environment vs a pure software-play startup like environment, the disadvantages of a 3 month coding period (see here to know how this can be possible) for the entire year starts to become extremely obvious.

Loss of familiarity with code

The 3 month coding period’s first causality is familiarity with the base code. Even the same code base you wrote an year back look alien. As we all know, unlike other engineering disciplines, the code is the real design when it comes to programming.

Code kept in head is a set of designs and interactions between data structures.


However even the best of code has small in-efficiencies. There are pieces that can be vastly improved, the ones with  bungled interfaces, sloppy designs, edge cases that one knows can break or modules that are downright ugly. However it is only the primary developer who is cognizant of these shortcomings. By forgetting code, or becoming unfamiliar with code, the possible improvements to these sloppy areas and modules suffer. Once this code is not looked at for an year, when someone else (most likely) or even the primary developer goes to this code, it is reduced to a jumble of interactions, which one must make sense of.

Many of the fine details are lost and you look at the code only from vantage point of high level interactions ie can do xyz, has messaging etc. But the knowledge of the caveats in your code, the hidden loop holes, and the hacks that where applied the first time over are lost.

The opportunity to improve, and change the areas that where lacking is lost here. A new image / idea of the code has to be build up from which to start hacking on the existing code. Any fixes or modifications incur the risk of bungling the original design precisely because the familiarity with the code base is lost.

This is why programmers sometimes prefer to re-write rather than maintain old code. The fight against never ending complexity develops hick-ups when done in such short bursty cycles of sporadic coding exercises.

No longer in touch

One of the worst kept secrets of coding is that, being a programmer is much like being a swordsman. If you do not practice daily, you become dangerously slow and outmoded. You might know all the moves, but you would not have perfect recall, the reflexive reaction that can be a life saver.


Similarly if you no longer code every day, you might know the basics of the data structures but you cannot be as fast and as correct as someone else who have been writing code daily. Apart from the obvious stops to look up data structures, api calls and such, you start forgetting the details, and side effects of the API’s, which means for all practical purposes your code is no longer clean and carefully written. At this point quality of code suffers.


The first casualty is the engineering culture. For lack of anything else, engineers start to game the system, reflectively, without consciously being aware of it, due to appraisal implications. Most of this is usually observed and learned from more successful engineers who have taken the same route.

The *implicit thought process* and actions go along these lines

  1. You need to achieve something every fiscal
  2. I create great code – but why am i not successful?

No real coding targets

In the presence of a cycle that disallows coding / feature creation for the better part of the year, programmers have to resort to make-believe to meet their hopes of how they perform in the appraisals.

Ideally the appraisals for software engineers should have dealt with things like –

  1. no and type of features they where able to produce
  2. The quality of the designs
  3. Code quality
  4. No of bugs that where observed per line of code.
  5. and other such measurements related to code

But the 2-4 month coding cycle, ensures that a single person can only deliver one feature and no more. The quality of the feature itself is of not much concern, since they are not measured either. So how do you get ahead of your colleagues in appraisals ?

Weasel Dictionary Starts – Initiative, Impact, Communicate, Perspective etc


Folks can be extremely innovative when it comes to gaming the system. This is a gradual process and often learned from observations of their peers who magically seem to achieve high grades despite their low coding prowess / output.

The magical lessons learned for a business transformation for a pure coder, would then mean more activities, which are anything but coding. These would probably go along the lines of

  1. Communication
  2. Collaboration
  3. Initiatives
  4. Vision statements
  5. Visibility
  6. Impact
  7. etc

Soon people start being more vocal / outspoken and argumentative in a clever sort of way. They become interested in giving out more presentations and writing more forceful mails and everything and anything that can make a positive impact on their appraisal sheet apart from pure coding.

This effort which resulted from not having any solid work to do, soon degenerates into an effort to avoid all coding and into translating into roles that give them more visibility and aid their impending changing over to a management career track. The
side effects are all arguably good but


Where in all this does the code creation take place? Instead of running the show with a tight 3-4 skilled developer team, double that number of  developers (all equally vocal, solution oriented and customer driven) are now required.  Of-course there is not enough work / money to pass around, which means all these folks are going to be even more vocal, solution oritened and customer driven than before.

Its a sheer uphill task getting such really experienced management type coders, to get some work done, after their drastically larger communication requirements and visibility needs are met.All this translates into visibly higher man power and resource requirements to get any work done.

Management complications – percentage time and context switches

The higher resource requirements means that there are often work left un-done from other areas. Management tries to juggle this by allotting percentage of a developers time across different projects.

  1. 20% on answering queries for really old project
  2. 60% on developing new feature for current project
  3. another 20% on handling bug fixes for the previous release.

All this generates tons of emails, which cause you to switch between many threads of thoughts, which is nothing but more and more context switches for the developer concerned. This again drives down productivity as it is quite well known that human task switches drives down productivity.

How would you fight this scenario?

Now, that is the correct question, the bitter pill no one really likes to know about. Lets try to take this up in the next and final installment of this series.

Meanwhile please leave any comments if you know of any good ways to arrest this rot.