Programmers expect their code to live long and prosper
The survey was recently carried out by Karoline Klever, a developer in Norway currently working as a consultant for Epinova. Almost 300 developers took her online poll about the life expectancy of software code. Klever recently shared some of the survey results on her blog, and subsequently answered a couple of questions that I asked her via email.
Among her findings were that developers expect their code (both past and present) to be used for many years. 62% of respondents believed that code they wrote 10 years ago was still in use in a production environment (20% weren’t even writing code that long ago), while 63% expected that code they were currently writing would still be in production use in a decade.
Interestingly, though, the majority of respondents also admitted to being to rewriting rather than fixing legacy code. 65% said they would rather rewrite a piece of existing code than debug and fix it, while 61% said they had at some point advised rewriting a piece of code simply because it would be easier than fixing. As Klever pointed out, these two set of findings (expecting your code to live long while being quick to rewrite legacy code) are somewhat contradictory. “If that is the case,” she told me, “doesn't it increase the chances of someone else rewriting your code before it reaches its 10 year anniversary”
The biggest surprise of the survey to Klever, was that developers don’t agree on what defines “legacy” code. When asked “In your opinion, what makes code ‘legacy’” the top responses were:
These mixed results, actually, have been seen before. For example, when the question came up on StackExchange a few years ago, answers were again all over the map. with the most popular answer being (essentially) that legacy code is “Any code that has been delivered.”
“Developers have very different opinions as to what legacy code is,” Klever told me, “and it will be very interesting to investigate whether your definition of legacy impacts how quickly you decide to throw away and rewrite a piece of code instead of debugging and fixing it.”
Asked for her own definition of legacy code, Klever told me “For me, code becomes legacy when continuing maintenance becomes more expensive than rebuilding/rewriting it. Whether this ‘tipping point’ is reached because of badly written code or outdated technology doesn't matter, these are all factors that contribute to code becoming legacy.”
I guess we can add “What makes code ‘legacy’” to the list of things programmers like to argue about.
In any case, Klever will be sharing more results and insights from her survey this October at Leetspeak in Stockholm. She plans to publish her presentation and all of the poll results on her blog sometime after that. I look forward to seeing what other light her survey will shed on the life expectancy of software code.