Investing into code improvement is a dual edged sword: on the one hand you know that if you don’t improve your code you’ll get slower over time. On the other hand improving your code does not deliver tangible value to your users. So how do you know whether you’re on track?
Track the time a user story needs from idea to production
If that time is getting longer you’re off track: your code is slowing you down. It’s time to invest more into improving your code.
Measure the number of bugs per code push
If that number increases, you’re investing too less into code quality. Build quality in by writing automated tests upfront and by streamlining your code base. Rip out over-complicated stuff which people fear to touch because it breaks every time they do.
Are you spending too much time gold plating your code?
If the above measures do not move in the right direction even though you’re trying to keep your code as clean as possible you’re optimizing the wrong stuff. Try to find those areas in your code which are worth improving and focus your improvement efforts there.
Don’t try to improve stuff which is never touched again
It’s only worth changing even the worst piece of code if you’re going to touch it again. While it sounds like a good idea to ensure that all your code adheres to your coding standards, that’s not feasible most of the time.
Make sure you put the right measures in place to find out whether you’re investing too much or too less into improving your code. What is your strategy to balance new features against code improvements? Please leave a comment below.
Agile Web Operations 
Re: “Measure the number of bugs per code push”, do you have any suggestions for how to do this? Specifically, how do you relate the discovered bug back to the pushed code?
There’s going to be lag between the push + observance of the behaviour, so whatever stats you’re generating are going to be delayed, and thus need to be viewed through the prism of long term performance.
LikeLike
To measure the number of bugs per code push is nice to wish,
but u should think about it twice. How many tasks do you need to push the whole code for a feature. Have you divided yor task in a right manner? Pushing too much reduces maybe the number of bugs, less pushes due to increasing bugs maybe. Sometimes the same kind of bug happens in many pushes. And not every developer do the work in the same way. There are people who practice more TDD, others more BDD and so on
If your team is a whole unit, who acts in the same way, it could maybe work to measure bugs in a properly manner. But i think the more important focus should be on the kind of bugs not on the number. The number should show u only if a threshold is exceeded e.g. on A bugs to get the focus again on the big complaints 😉
LikeLike
As writely said its a dual edged sword:
My take:
Is the code going to remain usable and salable for next 5 yrs-if yes invest in its improvement.
Why: New features components will /may get added during this 5 yrs which would be easier integrated with a good quality existing code.
If not the bad existing code may render the user baffled with ever increasing performance issues.
LikeLike