You can’t always develop features

hsoi blog, talk Leave a Comment

Rebel Labs performed a survey to examine developer productivity. While limited in scope, the survey did raise some useful points.

Technical Debt is work pushed off in favor of other work. Code Quality, in their survey, is a measure of how many critical bugs are in the software that you ship; this is most often measured by the level of bugs you find AFTER you have shipped. These two issues stood out to me because they both often are rooted in the same problem: they aren’t new features.

See, to those in charge of the business (i.e. the ones that care about money and thus sales), they need things they can sell. New things, fancy things, things to keep the product competitive. Certainly these are important and must be developed, and I do not deny that there’s no good sales pitch in “now with less bugs!”. However, incurring technical debt, like any debt, will eventually make any tower crumble. Not taking time to go back and fix known bugs and other quality issues leads to lower quality, which in turn will affect sales because your product will be reviewed as buggy and of poor quality.

It is important in every development cycle to allow the developers to take care of old business and handle needs that may not directly translate into a saleable feature, but are what will enable the product to have a longer and better life. It’s a delicate balancing act, and it often takes an experienced hand at the helm to decide which tasks should be handled now, and which to continue to defer while still ensuring new features and growth can occur. To only press forward with new features and never take time to address old matters, well, you’ve played Jenga: you can only keep rushing things out for so long; take a little time to reposition those lower bars, ensure the base is stable, and you can build a winning tower

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.