Our team is about to start a new phase of development on the net management product we are building. I was pleasantly surprised when we actually got allotted some time to make any code cleanups we thought fit.
If you do not know why this is surprising, read on.
A Typical Development Cycle
The last iteration of our development was finished six months back, followed by six months of various levels of testings and releases. Meanwhile, the developers were kept engaged in some form parallel activity, on support on existing products or investigations for the new requirements. This makes the best use of expensive developer time that there is and is standard practice in the industry.
The next set of features to be developed, will be taken up after a hectic bout of activity revolving around spec review, more investigations, wish bug scrubs and feature negotiations, together lasting for about two months or so.
If you have been doing the maths all along, you would have noticed, that it would be a hectic six to eight months break after which, we would be taking up the original code base which we had been working upon, in our last development iteration. Indeed, by this time, the distant memory of my code base having a Class CAuntMolly, that has a wart in her hind side or the method Jump() that actually stands up and sits down real fast instead of really jumping, have begun to fade from my grey matter.
In fact it takes a considerable effort for me to swap back in, the nitty-gritty’s of the design and frameworks created so long back. (everyone knows that reading code is hard) Even the comments, if not done properly makes little sense when reviewed afresh. Given this scenario, what would you tell the odds are, on creasing out all those little imperfections, knowledge of whose existence, is locked away somewhere deep in the recesses of my brain ?
After one more round of hectic development, I wouldn’t be surprised when i pick up the code next time around, to see another feature that depends on that wart of CAuntMolley’s being exactly on her left cheek. Give it some more time and you would soon have a string of related exponentially complex features (each all the more important of course) all of which depend on the wart on the left cheek. You get the idea.
(Tip : Reason why you ought to make a note of all those corners you skipped – at the very least it will help the next developer to better see what he is walking into)
I did consciously leave the imperfeactions in my code base, making a note to get back to it sometime later. Only, that “sometime” never quite came to pass, the code base having gone into freeze mode once the test cycles began. What was the time that was saved? I wouldn’t wager more than 2 days saved in not moving that wart out of my code. However, at the time, that 2 days was hard to come by. Across the code base, i might be able to count close to 2-3 months of short cuts taken in similar fashion. The product arguably shipped that much faster too in all probability, and as long as nobody really got hurt, things were fine. But at what cost?
The time saved in not refactoring the code actively is only going to save some finite time upfront, in getting the first one or two versions of code out of the door. These savings are like double entries that gets accounted in someplace else. Only in this case, when the costs are accounted, it might turn out that you end up paying double or triple, in maintenance costs and in time to add new features later on. Customers waiting months on end for patch after patch are not going to be amused either. Continue on the same vane, and you could have your own death match running in no uncertain terms.
So you bet, i am impressed favorably by the time allocated up front for code cleanup on our product. You could argue that it might have been better to produce great as in 1005 perfect code in the first place. Usually that is a function of the kind of team you have and the quality or the strictness of your review process and such. But acknowledging that you might have an issue and tackling it pro actively takes guts that people rarely do. (Having a strong management that can push back on resourcing pressures helps)