In a conversation with a fellow software developer, he stated that all code should have an expiry date. I must say, I like the idea of setting an expiry date for code I write.
The author(s) perceived quality of code should determine its expiry date.
Some example questions to consider:
- How stable, complete, and validated were/are the requirements (functional and non-functional)
- Was the code rushed to production? Or was it developed with care and attention to detail?
- Is it using an antiquated or experimental technology or exotic/experimental/not widely used programming language?
- Does it have tests?
- Was the code written after the tests?
- Was it reviewed and/or pair programmed?
- ...
Answers to the above example questions and others can help determine until what date code is supposed to be used. By stamping the code with an expiry date, a developer or a team makes a statement on the quality practices used to produce it.
Another question is: who should set the expiry date? The developer? The code reviewer? Some other stakeholder? A combination of all?
I must say that there is some perversion in this. The expiry date makes anyone using a piece of code after that date responsible for their actions. Like eating yoghurt after the expiry date. You decide if you want to risk eating it or not.
Thye expiry date should be dynamic, if the code gets revisited, refactored this should have an impact on the expiry date.
What do you think?
Top comments (15)
Some random thoughts:
I'd add "Does it work?" or "Does it work in current environments, as it did, when it got written?" to the list. And if it works, do the other points really matter?
Aren't you always responsible for your actions, especially when using other's code?
Hi,
I was assuming the code was behaving has expected. I did not approach this from a correctness point of view but rather from a quality point of view. For me all other points matter we tend to maintain code more than create new code.
Thanks for your contribution
For OSS projects for example is a lot easier to know when the project dies. When there is no one left to support it, and no one forks it then it dies. It may still work but no one maintains it anymore. You have various insights for projects hosted on GitHub, though you can't solely rely 100% on that.
The project should have tests, of course. A well made software in this day and age should live for at least 3 years without major rewrite. Adding quick fixes diminishes the life expectancy of the software. Adding features with the required amount of refactoring should at least ensure the target expiry date, if not prolong it.
Sometimes we have to rush the project, sometimes we don't know enough about the problem area, or we don't have the resources needed. In these cases the life expectancy is much shorter, because the maintainability costs will either be too high, or a complete rewrite will be needed long before the expiry date.
When I wrote my post I was not thinking about OOS projects at all, I was writing from enterprise closed source code.
Thank you for your contribution to the discussion.
I think "n code changes before mandatory refactoring" might be a better idea, because untouched code doesn't tend to get worse. Updating the copyright date should be counted as a code change, too, so there's an implicit expiry date. Depending on your requirements, n can be a function based on the complexity of the code (the more complex, the fewer changes there should be before taking the time to refactor it).
I like your idea, just not sure how to define n.
Thank you for your contribution to the discussion.
It depends on your requirements. A good starting value would be 5 changes to a function of normal cyclomatic complexity (5); whereas a higher complexity should allow for less changes before refactoring.
In this case, n = (5 changes * 5 average complexity) / cyclomatic complexity of function/file.
If you find out that you want to be more averse to higher complexity, you could also square the complexity: n = (5 changes * (5 average complexity)² / (cyclomatic complexity of function/file)².
Very cool, don't leave this in a comment, I encourage you to post about this if you haven't already.
By these questions one could estimate the code quality and it doesn't change with time. The only point which might have something to do with time is whether the code is using an antiquated or experimental technology or language.
I believe the problem we're trying to tackle here is: who is responsible for maintaining the code once it has been released? One article on the topic I find worth reading: blog.codinghorror.com/the-noble-ar...
"one could estimate the code quality and it doesn't change with time".
I agree that code does not change with time, but other things change. New tools, languages, techniques, security requirements, performance requirements, scalability requirements, environments its used on, ...
Thank you for your contribution to the discussion.
I see what u mean, however I think that if I am using some simple code that has maybe only one line(e.g. a javascript button for previous page),I would not only forget, but also doesn't even want to take care that line( on every single page) of my website. Not even once a century!
Then you don't define an expiry date for that code, I'm not stating this should be mandatory for all code :)
Thank you for your contribution to the discussion.
That's a generally good idea. In case it has a dependency on an external contract which very likely to be changed or updated - e.g. github api, or maybe dynamically loaded ddl or even jquery from a vendor site :).
I think this revisit period should not be less than 1 year though otherwise it smells like that software has some technical debt.
Other topic is security updates.
Hi Pedro,
long time no see ! I wonder if the code we've written @ Volvo Ghent for PBP is already expired ... or still "in the fridge" :)
Grtz,
Sven.
Hi nice to hear from you again,
Mine has certainly expired :) long time ago.
Pedro