As engineers, we usually have a drive to make code better, to make it beautiful. While making code better is a good thing, too much of a good thing can be, well, not so good. Beautiful code makes us happy, but usually happiness is not sustainable. There is horrific code out there that is being used and making money. On the other hand ugly code is probably code that is incurring technical debt and holding the business back. Being able to see where your code is on this spectrum is an art that involves some hard questions.
Previously, we raised these questions: How do you decide where you are on this continuum of perfect code and profitable code? When should you spend more time cranking out code so you can make money now, and when should you spend more time beautifying your code so you can make money later? Or is this a false dichotomy?
To start, this is not a false dichotomy. True, you should be taking some reasonable effort to write with some level of quality while you are writing in the first place. But in the end time is a limited resource and you will always have choices about how to allocate it.
What follows are some rules of thumb based on my own experience about how to determine where you are on this continuum. Asking and answering the following questions should help you discover when to spend your time more one one side or the other.
1) Where is the software in its life?
If the software is early in its life (say in a startup, or software in its first year) then making money in the short term takes priority so that the company can survive long enough to make money in the second year and so on in the long term. By all means be responsible during development and keep an eye on the quality of your code, but development effort should be focused on bringing the product to market and competing in the here and now.
Conversely, if the software is late in its life (say, 5-10 years old or even more) then it’s likely that long-term maintenance can be given equal or higher priority over regular feature work. Customers will expect stability from a mature product, and stability comes best with code that is easy to change without introducing new bugs.
When moving between these stages, the company needs to look at the long term viability of the software. There is a danger that the engineering culture gets stuck in “startup mode” and never shifts into “sustainability mode” – potentially resulting in the extreme case of progressively worsening code. Engineering and Management must be vigilant that the shift occurs properly or the company will pay the price down the road.
2) What are the trends on the estimates?
As people make estimates on their issues, if they see that their estimates are low (meaning their issues take longer to resolve than was estimated), they will automatically compensate for the next estimate. If the next round comes and they compensate but are still low again, that means the code is getting harder to maintain over time. If you are adjusting for your low estimates but it seems like the estimates are still low sprint after sprint, it is taking longer and longer to make changes. At this point it’s time to start allocating more time towards, say, refactoring work and code cleanup. Every piece of software has its dark corners, we all know where they are!
3) What are your code quality metrics?
Static analysis of the code can give you some direction as well. Any classes with a cyclomatic complexity metric of over 10 should be given a good hard look and scheduled for refactoring, and anything over 15 should be scheduled for refactoring with a high priority over other code work. These levels have been shown to be fairly dangerous and bug-prone.
To sum it up: these are just some ideas that come to mind that I feel would help to decide whether to spend more time cleaning up vs more time writing new code. If you have ideas and want to share what works for you, feel free to share!