DEV Community

Should code have an expiry date?

Pedro Moreira Santos on March 24, 2018

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...
Collapse
 
niorad profile image
Antonio Radovcic

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?

Collapse
 
pedromsantos profile image
Pedro Moreira Santos

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

Collapse
 
simov profile image
simo

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.

Collapse
 
pedromsantos profile image
Pedro Moreira Santos • Edited

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.

Collapse
 
lexlohr profile image
Alex Lohr

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).

Collapse
 
pedromsantos profile image
Pedro Moreira Santos • Edited

I like your idea, just not sure how to define n.

Thank you for your contribution to the discussion.

Collapse
 
lexlohr profile image
Alex Lohr

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)².

Thread Thread
 
pedromsantos profile image
Pedro Moreira Santos

Very cool, don't leave this in a comment, I encourage you to post about this if you haven't already.

Collapse
 
itenev profile image
Ивелин Тенев

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...

Collapse
 
pedromsantos profile image
Pedro Moreira Santos • Edited

"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.

Collapse
 
pixelimplosion profile image
EnRico

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!

Collapse
 
pedromsantos profile image
Pedro Moreira Santos

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.

Collapse
 
msoedov profile image
Alex Miasoiedov

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.

Collapse
 
hcd profile image
hcd

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.

Collapse
 
pedromsantos profile image
Pedro Moreira Santos

Hi nice to hear from you again,

Mine has certainly expired :) long time ago.

Pedro