Which is the norm, not the exception. Really good devs (which I’m not) are capable of delivering clean, modular, readable and maintainable code under pressure, working in a team with other people, with unclear requirements.
Most of the unmaintainable code I’ve seen is because businesses don’t appreciate the need to occasionally refactor/rewrite or do anything to maintain code. They only appreciate piling more on. They’d do away with bug fixing too if they could.
This is why AI coding is being pushed so hard. Guess what’s great at piling on at 30x speed? If piling on is all companies appreciate then that’s what they’ll demand.
For examlle: It’s entirely possible that a synchronous state machine worked for the previous needs of the software, but it grew to a point where now that state machine is unable to meet the new requirements and needs to be replaced with a modern fam with asynchronous singals/delegates.
Just because that system was replaced doesn’t mean that it wasn’t maintainable, wasn’t readable, or easy to understand. It just wasn’t compatible with the growing needs of the application.
I disagree. Rewriting is a core component of maintaining a code base. It’s the evolution of code. Not rewriting and hooking in some janky way is much worse. No one can see all the possible needs of code the first time they write it. Or even the tenth. Updating the code by rewriting sections is the healthier way to use everything you learned since the first time you wrote it to keep it clean and improve it.
Well, if rewriting is maintaining, everybody can write maintenable code.
Did it become a mess? Rewrite time!
For me the art is writing it so you don’t need to rewrite and you don’t need a janky temporary permanent workaround if requirements change. Clean interfaces, SOLID, plug-ins, etc. Can’t do it myself, but the legendary 10x devs usually do.
The most maintainable code is built to be replaced with minimal impact.
How much of the program will must be replaced if you remove one module? If you need to replace the entire program, then your program is not maintainable. Too much is heavily dependent on this module.
I don’t believe in code that never needs a rewrite, but scalable code should be compartmentalized and future-proofed to the point that the next rewrite can be pushed as far into the future as possible. Me personally, I tend to discover what these best practices are during those rewrites.
All code is maintainable with enough time and money.
But yes, well structured code where those rewrites are minimal is the goal.
There probably is a threshold where the amount you have to rewrite becomes too high. But with each rewrite, hopefully the next time you have a section you need to redo its smaller that before. Eventually going from rewriting a couple thousands of lines to just a hundred or so on the 5th iteration.
That’s just the norm tbh. You learn new techniques, the language gets new optimizations, keywords and shortcuts. That doesn’t mean your code is unmaintainable.
I rewrite it because it becomes a mess of asymmetric assumptions, weird dependencies and hacky extensions, I can’t really blame the language for that one.
It really depends on the situation. Can I write maintainable code? Yes, to the extent that the average senior dev can.
But that isn’t the same as being afforded the chance to write maintainable code. I’ve been part of teams where the timeline is so tight that technical debt is just a thing that builds up to be dealt with “later” and more stress is put on getting things done instead of keeping things maintainable.
The fact of the matter is that humans can while LLMs currently can’t.
On top of that, a human dev is going to be able to understand context a hell of a lot easier if they’ve previously worked on it, even if the code is less maintainable.
ITT: AI induced dunning-kruger. Everybody can write maintenable code, just somehow it happens that nobody does.
Every decision I’ve made to write code with poor maintainability was driven by time pressure to deliver
Which is the norm, not the exception. Really good devs (which I’m not) are capable of delivering clean, modular, readable and maintainable code under pressure, working in a team with other people, with unclear requirements.
Most of the unmaintainable code I’ve seen is because businesses don’t appreciate the need to occasionally refactor/rewrite or do anything to maintain code. They only appreciate piling more on. They’d do away with bug fixing too if they could.
This is why AI coding is being pushed so hard. Guess what’s great at piling on at 30x speed? If piling on is all companies appreciate then that’s what they’ll demand.
This 100%
My company is totally like this. If you don’t write a shiny new feature immediately, you don’t last.
Many opensource projects are in same state, I know for sure my projects become spaghetti if I work more than a year on them.
Besides, I’d argue that if you need to rewrite (part of) it is because it wasn’t maintainable in the first place.
I disagree.
Rewrites can happen due to new feature support.
For examlle: It’s entirely possible that a synchronous state machine worked for the previous needs of the software, but it grew to a point where now that state machine is unable to meet the new requirements and needs to be replaced with a modern fam with asynchronous singals/delegates.
Just because that system was replaced doesn’t mean that it wasn’t maintainable, wasn’t readable, or easy to understand. It just wasn’t compatible with the growing needs of the application.
It can, but usually that’s not the case.
I disagree. Rewriting is a core component of maintaining a code base. It’s the evolution of code. Not rewriting and hooking in some janky way is much worse. No one can see all the possible needs of code the first time they write it. Or even the tenth. Updating the code by rewriting sections is the healthier way to use everything you learned since the first time you wrote it to keep it clean and improve it.
Exactly. Elegant code requires domain expertise, which no one has on during the first attempt.
Strident attempts at elegance during the first domain-expertise-free try tend to just result in different kinds of shitty code.
Of course, experienced programmers can obviously achieve lower shittiness, from day one.
But truly elegant code requires exploring the domain, and learning what works there.
Shitty or barely-good-enough code often walks so that elegant code can someday replace it.
Well, if rewriting is maintaining, everybody can write maintenable code.
Did it become a mess? Rewrite time!
For me the art is writing it so you don’t need to rewrite and you don’t need a janky temporary permanent workaround if requirements change. Clean interfaces, SOLID, plug-ins, etc. Can’t do it myself, but the legendary 10x devs usually do.
The most maintainable code is built to be replaced with minimal impact.
How much of the program will must be replaced if you remove one module? If you need to replace the entire program, then your program is not maintainable. Too much is heavily dependent on this module.
I don’t believe in code that never needs a rewrite, but scalable code should be compartmentalized and future-proofed to the point that the next rewrite can be pushed as far into the future as possible. Me personally, I tend to discover what these best practices are during those rewrites.
All code is maintainable with enough time and money.
But yes, well structured code where those rewrites are minimal is the goal.
There probably is a threshold where the amount you have to rewrite becomes too high. But with each rewrite, hopefully the next time you have a section you need to redo its smaller that before. Eventually going from rewriting a couple thousands of lines to just a hundred or so on the 5th iteration.
Can I, sure. Do I give af since my company doesn’t care about me as anything other than a number in a spreadsheet, no.
Well, even for my private projects that I care about I end up having to rewrite every few years.
That’s just the norm tbh. You learn new techniques, the language gets new optimizations, keywords and shortcuts. That doesn’t mean your code is unmaintainable.
I rewrite it because it becomes a mess of asymmetric assumptions, weird dependencies and hacky extensions, I can’t really blame the language for that one.
It really depends on the situation. Can I write maintainable code? Yes, to the extent that the average senior dev can.
But that isn’t the same as being afforded the chance to write maintainable code. I’ve been part of teams where the timeline is so tight that technical debt is just a thing that builds up to be dealt with “later” and more stress is put on getting things done instead of keeping things maintainable.
The fact of the matter is that humans can while LLMs currently can’t.
On top of that, a human dev is going to be able to understand context a hell of a lot easier if they’ve previously worked on it, even if the code is less maintainable.
Well, I interpret the question as “can you write maintenable code under typical corporate conditions and timelines”. Very few can, but I’ve seen them.