Monday, August 17, 2015
I'm currently working on a presentation called "What is the actual life expectancy of your code?" for Leetspeak in Stockholm in October. While researching this topic, I wrote down a series of questions I wanted to look further into, and last week I published a developer survey on Twitter that contained some of these questions.
The point of the survey was to get some statistics to back up the message of my presentation, and to see if other developers share my opinions and experiences. The number of responses I received surprised me, a total of 291 developers responded to the survey! Thank you so much to each and every one of you!
A lot of people asked whether I would publish the results, and my answer is: Of course! I won't make any comments to the results and my interpretations of them at this point in time as that would give away too much of my presentation. Neither will I publish the entire spreadsheet of responses before I'm done with my presentation, but I'm happy to publish the basic statistics right away. I must admit, I find some of them quite interesting!
As you can see, 63 people responded "Other" to this last question. Let's take a look at what their definition of legacy is:
"It's legacy to me if it's causing more trouble than it's fixing, which could be a combination of any of the above."
"I don't have a definition for legacy."
"It's legacy if you're scared to touch it for whatever reason"
"it is not in production or un-maintained 3rd party components "
"When code is written in such a way that only the one that orininally wrote it will ever understand it"
"Code is legacy if it is not in active development"
"I'd say it's legacy if that (part of the) code base is no longer maintained. For example, one module in an application can be legacy while the rest is being actively updated."
"It's legacy if the complexity is high and it's untested. Glue code doesn't always need tests."
"Whenever a developer doesnt care"
"As soon as it's written"
"If I wrote it more than 3 months ago"
"It's written in a language that is no longer supported or hasn't been updated/worked on for multiple years, or is written in a way which we no longer support - such as transitioning from asp.net web forms from mvc, web forms would be considered legacy"
"I don't know"
"noone dares to touch it"
"When it no longer works"
"It's legacy if it requires changing, and it proves difficult to refactor into a state from which that change is easy."
"If the codebase hasnt been touched in X years"
"It's legacy if it's using patterns and solutions that are now considered a poor solution, or just better ones exist."
"It's legacy when you're afraid to change it"
"Old and lacking documentation. Unsupported platforms"
"If it lacks any tests at all"
"It's not legacy if you're running it, it may be a debt of understanding."
"It's legacy when the team responsible for it is scared of changing it."
"It's legacy if it's unmaintainable"
"not continuously maintained, no docs, platform out of date"
"It's legacy if the code is there but the meaning is not."
"Evertime I open a file and it is not empty, it is legacy"
"It's legacy when there is no reasonable upgrade path to a modern system."
"It's legacy if we're afraid to change it"
"No team knowledge of the code"
"It's legacy if it's a solution in search of a problem (e.g. violates YAGNI)"
"It's legacy when it's easy to make mistakes while trying to understand or modify it."
"Nobody did a change to the code for 6 months."
"design has terrible and obvious flaws that impede maintainability"
"If no one fully understands what it does and how"
"After the first commit, it's legacy."
"When it's intent is no longer obvious (having newer frameworks help that, unit tests too, etc)"
"code should be living. Legacy is code you cannot change for technical reasons (e.g. no access) or because you don't understand what it does."
"if development on the project has stopped"
"It is legacy if I don't agree with how it was written."
"If it has not been (properly)maintained"
"when it becomes too hard to maintain (adjust to current business needs, fix bugs, etc);;"
"if it can't be easily changed in the face of new requirements"
"It's legacy if we no longer recommend external people use it."
"Changes in Apis, data formats can all push code into legacy phase of life "
"When people responsible for this code has left"
"It's legacy if everyone is afraid to change it."
"It's legacy if it has stopped evolving new features while its maintainability has degraded from lack of use."
"Unsupported Technologies (i.e Oracle Forms 6)"
"as soon as the requirements change and code isn't updated accordenly due to too high investments"
"Another product has replaced it and still migrating systems/customers off it"
"If it is hard to understand, change or easily build on a new machine "
"If there's a newer version in production"
"It's legacy when it's about to be replaced but must live side by side with the replacement for a short while "
"It's legacy the moment it gets written"
"If compilers or other required build artifacts are no longer available"
"In general it is legacy as soon as it is very hard to maintain. Old languages/framework and a lack of unit tests is a factor, but mainly badly written code."
"no longer used or in the process of being replaced"
"If not regularly maintained"
Pretty interesting list, don't you think? So what do you make of these results? Did any of them come as a surprise to you?