A bit of wisdom from someone who has deleted a lot of code; including my own code.
Backend code has a longer shelf life than frontend code. I've been doing Java for over two decades. A lot of the early libraries and tools are still around and are still getting active maintenance and I still use them. I have code that I wrote close to a decade ago that is still used and relevant. Good backend code can stay relevant for a long time. I use some Java libraries that predate anything you might consider super dated on the frontend.
Frontend code has a shelf life of about 1-2 years before people start getting nervous about new frameworks, a new design, or some other excuse to start from scratch. Frontend code that survives beyond that is generally expensive to maintain. This is OK. It means you have an reason to not over-engineer. YAGNI and KISS are good principles.
Other people's code almost always ends up being retired early. I've learned that the problem is that good handovers are rare in our industry. Getting this right and gradually transferring ownership can create enough buy-in from the new people that they may end up being confident doing maintenance. Failing to do that they will end up replacing rather than fixing code.
Code that tries to be clever is the worst. Your pretty is my unreadable. Cryptic one-liners that show of your mastery of dark generics voodoo or typesystem hackery is not a good thing. I like stuff that does exactly what it says it does and nothing more. I hate languages that encourage these things and seem particularly susceptible to code rot: calling out Ruby and Scala here. These languages seem to attract exactly that kind of behavior.
Prototypes and mvps have a habit of becoming the thing. Starting from scratch two months into a project is a hard sell in most places.
Many startups fail in the phase where they are trying to rewrite their MVP because it is unfixable and only few have the runway to survive long enough to pull that off. Deleting code to fix code rot is a risky business and kills companies.
Maintenance makes up the vast majority of cost in our industry. Given that, developing from scratch can be expensive and still end up saving cost. If your existing design is holding you back, it basically becomes a tax on new development. Understanding cost is helpful in deciding what to delete and what to fix.
Understanding code metrics and their influence on maintainability can help you produce better code for the same cost. Anything with lot of lines of code and a huge number of imports has high coupling and low cohesiveness. You want the opposite. Some people refer to these metrics as the solid principle, which basically translates as doing things that help improve these metrics. It's not an OO thing and applies to any language. Lots of imports == bad. Thousands of lines of code in a single thing (module, class, method, function, lambda, etc) == bad. That simple. Any idiot can see at a glance of an eye what are the problem points in any code base. Simply look for the biggest files: that's where all the bad code is going to be.
Refactoring is key to keeping code relevant. Anything that you can't refactor will accumulate cruft and rot over time. Using languages and tools that facilitate this helps keep code stay relevant longer. You don't allocate time for refactoring it is part of what you do. Similarly writing tests is not a separate task.
If it is messed up or making your work harder, and you are not fixing or refactoring it, you are adding to the problem by working around it. That means you are piling technical debt on top of existing debt and are making it more likely that the code will be deleted sooner rather than later; including the stuff you are doing right now. It's that simple.
The boy scout rule is easy to explain and apply. Good developers leave a code base in a better shape than they found it with every commit.
Tactics and strategy of software development are such that planning for replacing what you are building causes you to build things such that that is easy and probably less likely to be needed.
Requirements are based on assumptions. Assumptions are subject to change as facts change. They always change and will end up breaking assumptions. No code is ever finished and you should judge it on its ability to be fixed for requirement changes. Those are inevitable. So, is code rot.
Thank you for reading and for your great response. It’s amazing what experience teaches us. I agree with your points.
A+ for your last point about adaptability. That’s the main reason why I write this blog. Happiness is based on freedom, and if your code prevents you from making easy changes... then you’re not free!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A bit of wisdom from someone who has deleted a lot of code; including my own code.
Backend code has a longer shelf life than frontend code. I've been doing Java for over two decades. A lot of the early libraries and tools are still around and are still getting active maintenance and I still use them. I have code that I wrote close to a decade ago that is still used and relevant. Good backend code can stay relevant for a long time. I use some Java libraries that predate anything you might consider super dated on the frontend.
Frontend code has a shelf life of about 1-2 years before people start getting nervous about new frameworks, a new design, or some other excuse to start from scratch. Frontend code that survives beyond that is generally expensive to maintain. This is OK. It means you have an reason to not over-engineer. YAGNI and KISS are good principles.
Other people's code almost always ends up being retired early. I've learned that the problem is that good handovers are rare in our industry. Getting this right and gradually transferring ownership can create enough buy-in from the new people that they may end up being confident doing maintenance. Failing to do that they will end up replacing rather than fixing code.
Code that tries to be clever is the worst. Your pretty is my unreadable. Cryptic one-liners that show of your mastery of dark generics voodoo or typesystem hackery is not a good thing. I like stuff that does exactly what it says it does and nothing more. I hate languages that encourage these things and seem particularly susceptible to code rot: calling out Ruby and Scala here. These languages seem to attract exactly that kind of behavior.
Prototypes and mvps have a habit of becoming the thing. Starting from scratch two months into a project is a hard sell in most places.
Many startups fail in the phase where they are trying to rewrite their MVP because it is unfixable and only few have the runway to survive long enough to pull that off. Deleting code to fix code rot is a risky business and kills companies.
Maintenance makes up the vast majority of cost in our industry. Given that, developing from scratch can be expensive and still end up saving cost. If your existing design is holding you back, it basically becomes a tax on new development. Understanding cost is helpful in deciding what to delete and what to fix.
Understanding code metrics and their influence on maintainability can help you produce better code for the same cost. Anything with lot of lines of code and a huge number of imports has high coupling and low cohesiveness. You want the opposite. Some people refer to these metrics as the solid principle, which basically translates as doing things that help improve these metrics. It's not an OO thing and applies to any language. Lots of imports == bad. Thousands of lines of code in a single thing (module, class, method, function, lambda, etc) == bad. That simple. Any idiot can see at a glance of an eye what are the problem points in any code base. Simply look for the biggest files: that's where all the bad code is going to be.
Refactoring is key to keeping code relevant. Anything that you can't refactor will accumulate cruft and rot over time. Using languages and tools that facilitate this helps keep code stay relevant longer. You don't allocate time for refactoring it is part of what you do. Similarly writing tests is not a separate task.
If it is messed up or making your work harder, and you are not fixing or refactoring it, you are adding to the problem by working around it. That means you are piling technical debt on top of existing debt and are making it more likely that the code will be deleted sooner rather than later; including the stuff you are doing right now. It's that simple.
The boy scout rule is easy to explain and apply. Good developers leave a code base in a better shape than they found it with every commit.
Tactics and strategy of software development are such that planning for replacing what you are building causes you to build things such that that is easy and probably less likely to be needed.
Requirements are based on assumptions. Assumptions are subject to change as facts change. They always change and will end up breaking assumptions. No code is ever finished and you should judge it on its ability to be fixed for requirement changes. Those are inevitable. So, is code rot.
Thank you for reading and for your great response. It’s amazing what experience teaches us. I agree with your points.
A+ for your last point about adaptability. That’s the main reason why I write this blog. Happiness is based on freedom, and if your code prevents you from making easy changes... then you’re not free!