The Reality of Long-Term Software Maintenance (construct.net) 43
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:You'd like to start over, but can't. (Score:4, Insightful)
Re: (Score:3)
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)
Yeah, after hitting "submit" I realized I should have altered the analogy somewhat.
Although it would be interesting to see someone try building a new ship while stationed on an existing in-use ship!
Re: (Score:2)
Yeah, after hitting "submit" I realized I should have altered the analogy somewhat.
Although it would be interesting to see someone try building a new ship while stationed on an existing in-use ship!
Towing around a floating dry-dock with an under-construction ship inside, having parts/materials/kabor delivered by another ship ... :-)
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:2)
I think it comes down to the null hypothesis, without evidence to the contrary assume that all the old cruft is there for a good reason.
The rewrite-in-place does have its own serious risks.
The standalone rewrite, when it fails, just means you have a dead side-project. But the rewrite-in-place can leave you with a half-complete frankenbeast that's even less maintainable than when you started. You really need to ensure that each incremental step is an improvement.
Re: (Score:2)
IF the team doesn't have the skill, then better to have them clean up what they already have. Otherwise they'll just make another mess by starting from scratch.
Re: (Score:2)
Is this the Wayland vs X discussion all over again?
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.
Re: (Score:2)
Sometimes it's better to just start over
Sometimes, but usually not.
I always think of Joel Spolsky's "Thinks you should never do" [joelonsoftware.com] article from 25 (!!) years ago when someone mentions The Big Rewrite. It came up again recently at my workplace for a large product we support.
Joel's opinion on this seem to have fallen out of favor in recent years (at least judging by how many articles disregard it when you search for the article title); I'm not sure if that's more due to the speed and nature of modern "agile" software development, or if it's starry-e
Re: (Score:2)
The way to learn to write clean code is to clean up your own mess, not to try again from scratch.
Old News (Score:1)
Re: Old News (Score:2)
Re: (Score:2)
Re:Old News (Score:5, 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!
Re: (Score:2)
I don't want t
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:1)
On the abstraction layer -- I suspect you've never had to work on a codebase that was written without abstraction and then later ported to different hardware platforms. Too much abstraction results in code that is bloated and slow, but too little abstraction results in code that is buggy as hell and impossible to maintain. Slow but correct beats fast but wrong every time in my book.
Re: (Score:2)
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...There is no reasoning with people who are of this mindset.
That's because they are mediocre programmers. A third party, with high probability, will in fact write better code than them. And they know it.
The way to "reason" with them is to help them improve their programming skill, so they can actually have confidence in their own code.
Re: (Score:2)
Re: (Score:2)
a comment is there to explain how and why you're doing something
Bingo. Where many newer (and not so new) devs fail on this is commenting on what the code is doing instead of why it's doing it or how it's going to accomplish some goal. While there are some times when "what" comments are useful - usually for convoluted or complicated code that is necessary to solve some problem or meet some performance - the vast majority of comments should help future devs understand the rational or method behind the code and not the code itself. Warnings about pitfalls like edge cases
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:4, Insightful)
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 software written in a big hurry by people who left the company long ago. Your day consists of attending the daily standup meeting, explaining what you accomplished yesterday so the Jira tickets can be moved to the right, and getting a new set of micro-assignments that you will plow into for the remainder of the day. You will contemplate doing this for the next several decades and try to justify it to yourself.
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:3)
And I was told by the sales guy that AI does it better and cheaper than humans!
This should be the job of government as well... (Score:2)
Maybe this should be the job of government as well. Governments are the ones that make physical transport, communication, and such possible. Perhaps having divisions to maintain and even perhaps replace software used by a lot of businesses would be a needed thing. For example, things like an OpenPGP program, or OpenSSL should be government maintained, or at least funded to assure a high trust level. Same with things that are needed, but are starting not to have updates. It might be good for some organi
Coding is not sotware engineering (Score:1)
'nuff said.