For those of us who don’t build software, it seems that code is constantly changing. Think of all the times you’ve had to update the OS or applications on your mobile phone or laptop. However, a new survey of software developers finds that the people who write all that code expect it to be used for a good long while.
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.
Code life expectancy is long
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.
Developers quick to rewrite rather than fix legacy code
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?”
Little agreement on what "legacy" code is
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:
- It’s legacy if it’s written in an old language, or uses old libraries and frameworks (chosen by 180 respondents)
- It’s legacy if it lacks unit tests (115)
- It’s legacy if everyone who wrote it are no longer on the project (102)
- All code is legacy after X number of years (77)
- It’s legacy as soon as it’s in production (57)
- It’s legacy if someone other than I wrote it (13)
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.