The Reality of Long-Term Software Maintenance (construct.net) 28
When developers boast "I could write that in a weekend," they're missing the painful reality that haunts software maintainers for years. In a candid blog post, Construct developer Ashley explains why maintaining large software projects is a burden most programmers fail to appreciate. "Writing the initial code for a feature is only a fraction of the work," Ashley explains, estimating it represents just "25% of the total work" in Construct's 750,000-line codebase. The rest? A grinding cycle of "testing, diagnosing and fixing bugs, optimizing performance, upgrading it to work with other changes, refactoring, customer support, writing documentation and similarly revising the documentation over time."
Ashley describes how accepting code contributions feels like someone offering to build you a free extension -- initially attractive until the roof starts leaking years later and the original builder is nowhere to be found. Meanwhile, your tenants (users) are furious, and you're stuck with "no good options." The post recounts Construct's own bruises: a community-contributed storage plugin still causing compatibility headaches a decade later, and third-party libraries that became maintenance nightmares after their creators vanished.
These experiences explain why seasoned maintainers eye large code contributions with deep suspicion rather than gratitude. "If you suggest some software project uses some code -- even a small amount -- will you be there in literally 10 year's time sorting out all the issues that arise from it?" Ashley asks. "Usually the answer is no."
Ashley describes how accepting code contributions feels like someone offering to build you a free extension -- initially attractive until the roof starts leaking years later and the original builder is nowhere to be found. Meanwhile, your tenants (users) are furious, and you're stuck with "no good options." The post recounts Construct's own bruises: a community-contributed storage plugin still causing compatibility headaches a decade later, and third-party libraries that became maintenance nightmares after their creators vanished.
These experiences explain why seasoned maintainers eye large code contributions with deep suspicion rather than gratitude. "If you suggest some software project uses some code -- even a small amount -- will you be there in literally 10 year's time sorting out all the issues that arise from it?" Ashley asks. "Usually the answer is no."
You'd like to start over, but can't. (Score:5, Insightful)
Re: You'd like to start over, but can't. (Score:2, Troll)
Re: (Score:3)
Re: (Score:2)
But sometimes it makes more sense to build a second ship alongside the first - then, when finished, transfer everything and everyone over.
Re: (Score:2)
"Can't replace the hull of the ship while it's sailing" ...
But sometimes it makes more sense to build a second ship alongside the first - then, when finished, transfer everything and everyone over.
While it's sailing? Think that through... :-)
Re: (Score:2)
I work on the plane while its flying every single day.
Re: (Score:3)
Sometimes it's better to just start over than trying to fix hacks on top of hacks. But that is almost always impossible for stuff that's needed for daily function.
The trouble with starting over is it often seems easier than it is because all of those weird bits are there for a reason, sometimes just bad architecture in the original system, but sometimes real requirements of the business logic.
I think the best approach is figure out the new "proper architecture" and then start rewriting a bit at a time. More work than a rewrite but more likely to succeed and you always have a working product.
Re: (Score:2)
To build on what you just said...
I am very wary of any argument that may boil down to "I do not not really understand what is going on here, but surely it will be easy to do better with a rebuild". Such claims are often founded on broad ignorance regarding the complexity of the real underlying requirements. And what I mean by "real underlying requirements" are those yardsticks by which the success of the project will be judged by the users/consumers who rely on the software. If the PRD was woefully incom
Re: (Score:3)
It's a double-edged sword...
C, you can just write everything yourself, and you never need to peer into someone elses black box, if some library goes obsolete, you can replace it with some effort.
C++, same as C as long as everything was using C bindings.
Every other language? You are up the creek without a paddle the minute the maintainer of that package stops maintaining it. If a new CPU type comes out, classic example (eg x86-64, ARM64, etc), or a new OS type that doesn't have that library at all.
PHP, all t
Re: (Score:1)
Example: air-traffic control.
Old News (Score:1)
Re: Old News (Score:2)
Re: (Score:2)
Re:Old News (Score:4, Insightful)
"How can you reduce the cost of maintenance?"
By taking the time to write clean, clear code in the first place.
But, of course, that's wasting time making it "pretty" instead of making listable features. We can't be wasting time on that!
This is why you need to write your own code! (Score:5, Insightful)
1. All the library crap developers add to solve problems they don't need. You're generally better off writing the functionality you require, yourself, than relying on someone else's library. There are cases where that's impractical, but, if you can write it, you probably should.
2. Lack of comments. To spite what anyone thinks because I don't care, a comment is there to explain how and why you're doing something. You want to leave those explanations in the code, so other developers understand why and what you were thinking. It might be a stupid idea or solution you came up with, but if you leave good comments, at least they know why you did what you did. I typically recommend a code base is at least ~50% comments because if you're commenting less, you're probably not commenting enough. This is combined with the documentation concern, your code should be self documenting, in that you can write a parser to turn the comments into the documentation. If your code can't turn out its own good quality documentation, you failed.
3. Stupid complexity. Just because you can write interfaces to interface to abstracted state machine interfaces, doesn't mean you should. Unless you're doing something very complicated, the simple and straightforward solution is almost always the right one. I've picked up old code bases that have so much indirection in them, you have to wonder if the developer was in some kind of LSD / DMT fever dream. The annoying part about this point, I know developers who argue the abstraction method is a better, more robust methodology, but they're wrong, almost always.
Re:This is why you need to write your own code! (Score:4, Insightful)
I couldn't possibly agree more. I would have given you mod points, but you already have a score of 5.
However....
If writing code for profit, sometimes you need a third party library for something your team COULD write themselves, but would take a long time doing it. The time savings is not only cost savings but it also gets you to market sooner, which can be critical if the business model involves long-term contracts.
So, I can see that as an excuse for using libraries for ordinary things.
There is also a strong subculture among developers that takes the exact opposite attitude on this. They insist that it is better to use third party libraries whenever you can. Their reasoning is that whoever wrote those libraries are both devoted, and specialists, so they will do a better job of it than you will. They will find and fix the bugs in it, so you don't have to. Same for security holes. And they are all computer science geniuses who will be able to make it more performant and less memory hungry than you can.
There is no reasoning with people who are of this mindset. They are every bit as stubborn about this as we are in our insistence that it is better to write it ourselves (if for no other reason than getting a solution that fits our needs exactly rather than something generic that we need to bend and warp our solution to even use).
I have seen similar passion in the insistence that coding to interfaces (plus a hearty dose of injection, inversion of control, and mocking for tests) is the one-size-fits-all pattern for coding all solutions. Their level of devotion to this is outright religious. The will not be talked out of it. The end result is almost always a huge codebase where 99% of your interfaces have only one implementation and you have to keep re-writing your tests because every other change is a breaking change (and the advocates repeatedly insist that our case is special and usually breaking changes are rare).
Re: (Score:3)
My bigger issue is honestly the comments developers don't use. I don't care if YOU unde
Re: (Score:2)
The reality is... (Score:3)
Reality checks (Score:2)
1. Management saying "if it ain't broke, don't fix it".
2. The software *works*. Why do you want to waste time and budget rewriting something that *works*?
3. You're sure you can rewrite it in a week, eh? With everything it does, including the stuff that looks weird that was added for serious reasons?
4. And how easy is it for the users to use your Wonderful New Code - have you don't any surveys/meetings with them?
I could go on for a *while*. Just one last piece of junk: in ten years at the NIH as a sr. Linux
Can't wait (Score:3)
Going to be a lot of maintenance work in 10 years from now.
Re: (Score:2)
Well, maybe. Apparently most AI "code" is so bad that people that could fix it might just walk away.
I learned that 35 years ago (Score:2)
In Software Engineering 101. 20% initial coding, 40% maintenance, rest other stuff. Anybody that does not know this is simply incompetent.
the reality of programmer jobs (Score:2)
You spend a lot of time and effort learning to write software, ideally because you like it and you are good at it. You go through any number of grinding interviews and tests to see if you know your "algorithms and data structures", that you "are a fit with the corporate culture", and eventually you land a job. You are all set to create awesome things nobody has ever seen before.
And then you find out that your job consists of fixing bugs and making minor enhancements to a huge creaking mass of legacy softwar
Making the decision (Score:2)
I've been involved with several legacy systems. We scrapped a couple and started over. We ported a couple more to new technology. The decisions involved several factors. How critical is this system to our business? How much work is involved in creating a new system? Are there dependencies we can't do anything about? What happens if we don't do anything?
Of the projects I've been involved in, we scrapped a couple of legacy systems and started over. One was core to our business but ran on bespoke abandonware
But AI Coded It! (Score:2)
And I was told by the sales guy that AI does it better and cheaper than humans!