Can we please stop putting forth this idea that features >>> reliable product? The amount of dev time that a company will save from removing technical debt will likely be more than the extra sales the company will get from a new feature. I look forward to the day where the executive team comes to the developers and ask why they are working on features instead of cutting down technical debt.
I had a Philippino friend who told me of his early experience in a Japanese development outfit - the team got praised by management (maybe not CEO) on performance improvements and code reduction. At the time I thought those priorities would never have flown in the US (though was of like thinking).
So this mindset does/did exist.
If are building something that will be sold, particularly in a competitive market, management will almost always believe that new features trump reducing technical debt. To a product manager, even four weeks of technical debt reduction sounds like "no new features for a month."
Yeah, but if you can't implement new features in under a month because the code is such a mess, then maybe spending a month cleaning it up will allow you to do more features in a shorter amount of time, thus increasing revenue faster than just hacking more features into the existing crappy codebase. Obviously it depends on the codebase, but you have to look at both long and short term goals to make good decisions.
<google google google>
Here - pont 5 in this post: http://www.joelonsoftware.com/articles/fog0000000043.html
It's hard to explain to someone who hasn't experienced it how much easier it is to develop in a bug free code base.
To paraphrase: We programmers need all the help we can get, and we should never assume otherwise. Careful design is great. Testing is great. Formal methods are great. Code reviews are great. Static analysis is great. But none of these things alone are sufficient to eliminate bugs: They will always be with us. A bug can exist for half a century despite our best efforts to exterminate it. We must program carefully, defensively, and remain ever vigilant.
It's a great philosophy or methodology, but it can be very hard to execute on 100%. In the real world there are deadlines and resource requirements and impatient clients and produce launch plans with set dates and trade shows starting next week and the Thanksgiving/Xmas launch opportunity and and and.
Better languages are possible. Provably correct software is possible. We really can eliminate bugs.
Ah cool, so you've solved the halting problem then?
It's like the difference between being able to express proofs in maths, versus having a method of deciding the validity of arbitrary propositions. We can certainly write programs that we can we can prove things about, but given an arbitrary program, we can't always tell whether it will do the right thing.
Even then, the software is provably correct according to some specification, which can still have bugs. No technology can fully prevent logic bugs.
At other places I've worked, I wouldn't raise an eyebrow if I found 3 bugs in a day, just trying to get other stuff done.
> As soon as you see a bug, you fix it. Do not continue on. If you don’t fix your bugs your new code will be built on a buggy codebase and ensure an unstable foundation.
Looking back to the codebases i've worked with, this advice seems extremely wise.
[1] http://www.gamasutra.com/view/news/279357/Programming_princi...
Improving and perfecting the code is a task that can take infinite amount of time.
At core all of Agile Software Development is aiming to mirror Lean in the manufacturing world. At the core of which is the concept of minimizing work-in-progress. Because WIP may result in waste if you subsequently find a problem that renders the WIP null and void. Hence the drive for continuous flow to minimize WIP and a "stop the line" mentality to spot and address issues when they arise.
I'm often amazed at how many people "doing" agile through sprints don't understand that the sprint is just an artificial mechanism to minimize WIP.
Not dealing with technical debt when it occurs is just increasing WIP.
Not always true (though it often is!), but particularly not always true in the timespan that the company needs to get sales in...
It might just affect development time of things interacting with the bad, old code - or make bugs harder to fix Changes to old nasty code will probably be hacky under the mentality "we're going to refactor this anyways, no point in writing clean code /now/"
Most old code (i've worked with) will function fine - it has for a while after all.
Very new to talking with execs and I don't know where to begin.