Eh, no. Good code is code that solves whatever problem needs to be solved, and does it on time.

That's not good, it's just working code, perhaps delivered on schedule, which are properties that pertain to good code also.

It may be useful 'as is' and generate revenue to them as sell crap, but still continues to be bad code.

'cos over here your maths doesn't work, anything that is going to be used by someone else should be maintainable, one-off solutions excepted. If someone else is going to use your code they need to be able to depend on it, use modules within it for undreamed of purposes and fix it when it goes bad (and it will go bad). Unless it is allowed for in the initial design and implementation you will pay far more to "retro-fit" maintainability

use modules within it for undreamed of purposes and fix it when it goes bad (and it will go bad). Unless it is allowed for in the initial design and implementation you will pay far more to "retro-fit" maintainability

By your own words, the things that will need changing are "undreamed of".

So all the effort you put in at the beginning to cover off all the possibilities that you can dream of--95% of which will never be needed--is wasted effort. And you won't have thought of the undreamed of things that are needed.

But it is almost always worse than that. All the complexity you added trying to facilitate all those things you predicted (guessed) might be needed, but never will, will make the adaptation to the one thing you didn't dream of 10 times harder.

So, now you wasted time and money up front, and it costs you 2x, 5x, ... more to make the change once you actually know what that change is.

Predicting the future is a mug's game. And the more obvious the future you predict seems to be, the harder you will be bitten and the more it will cost you when it doesn't come true.

More money has been wasted, more projects scrapped before they ever saw production, and more good money thrown after bad in the software industry because of whatifitis, and its close cousin, wouldntitbeniceifitis, than all other causes combined. And that includes crude, naive and just plain badly written code.

From experience, it is far easier to maintain, re-factor and upgrade simple, but crude code than it is to so for nicely structured but heavily nested O'Woe code written to try and cater for every possible future.

With the former you know that what code there is serves a useful purpose, even if it gets it wrong sometimes. With the latter, your first task is to try to work out what of the morass of code is actually ever exercised by real workloads, before you can begin the process of correcting its flaws or adapting it to new requirements.

Simple is always best. Even if you think something might be required at some point. Don't add it until is is required. Because you can bet your bottom dollar, that often it won't be required, but will get in the way of what actually is.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Your argument seems to support the claim that "bad things have been done in the name of maintainability" than argue Utilitarians claim that "maintainability saves effort in the long run".

Perhaps you're not allowing for the possibility that writing maintainable code can be done well. It can be done without significant increase in initial effort. For example using moose can both improve maintainability (adding attributes is easy, inheritance is easy), and it can save effort.



- Boldra

Unless it is allowed for in the initial design and implementation you will pay far more to "retro-fit" maintainability

Really? Do you have some data to back that up? Can you quantify that bold statement?

Note that I nowhere said one should write horrible code. But paying now for possible future happenings isn't always the smartest decision. Sometimes it is, and it's hard to know when that sometimes is. I'm not claiming I will always know when it's smart to spend more time now to save time later, but I do know it's certainly not always the case.

Heh.

I suppose that, at the time, the code I’m dealing with today “solved whatever problem needed to be solved, and did it on time,” but ... now it’s ten years later, and the code in question is still in service (and in front of the faces of literally thousands of people, and f*cking-up in front of every one of them) ... and, miracle of miracles, “maintainability” is suddenly a huge issue, indeed.

“Software has a life-span.”   Imagine that...   :-/

Sure. But how much of the code you have written needs to be modified after 10 years? There's a lot of code that's being written that either won't survive 10 years, or, after having survived 10 years, will do another 10 years without modifications.

It's often not wise to pay an extra cost *now* just so you *may* save some costs in the future. The time you spend now to make code more maintainable cannot be spend on writing code that generates revenue. That's 10 years of revenue you'd have to compare against the savings of having to deal with harder to maintain code 10 years from now. Now, in some businesses coding for maintainability makes sense; I'm not arguing that. But I take issue with blanket statements - just because it sometimes makes sense, doesn't mean it always make sense.

Around here, and I expect in most (if not all) cases of non-trivial code, "maintenance" starts during development. You don't have to wait 10 years before you suffer from poor maintainability, you don't even have to wait 10 days.

If it is not maintainable, debugging is harder. Adding features (aka development) after a mere weekend is harder. And as such, meeting the deadline is harder.

But I take issue with blanket statements - just because it sometimes makes sense, doesn't mean it always make sense.

Right, but how does your version of maintainable differ from your version of non-maintainable code?

For me it doesn't differ much

I will not work for anyone who thinks maintainability is not in the top 3 criteria code should be measured on.

I would like to spend my time creating new and interesting things, not cleaning up my predecessor's mess where fixing one thing creates two problems elsewhere.

I will not work for anyone who thinks maintainability is not in the top 3 criteria code should be measured on.

Which one do you sacrifice:
1. Does the job.
2. Is finished when needed.
3. Runs fast enough/doesn't consume too many resources.
Or let me ask it this way. Do you prefer to get your salary at the end of the month, or do you want to wait for the perfectly maintainable code that processes the payroll?

All of this seems to assume that any of these things are mutually exclusive with maintainability. I'll argue that only maintainability makes any of these even possible.

1. "Does the job". Requirements always change. Seriously, when don't they? Maybe at uninteresting places... Maintainability lends agility to code, so it can do the job that's required by the end of the project, not just what is thought is needed up front.

2. "Is finished when needed" Only maintainable, flexible code has any chance at all of being delivered on time while requirements keep changing.

3. "Runs fast enough/doesn't consume too many resources" Only maintainable code can be easily tuned and adjusted to suit performance or resource constraints. Non-maintainable code locks in specific algorithms and inflexible use-cases.

When you start developing software of any interesting scale, maintainability and good design go hand-in-hand. Only strong separation of concerns, loose coupling, and high cohesion allow the developers to work more independently with less overhead/communication required along the way. It also allows for cheaper junior developers to contribute to the project, implementing pieces of the design/spec without compromising the quality of the entire project. In the world of non-maintainable code, only the engineers who know everything about everything can even touch the code. Now that's expensive.

Poorly written code is just poorly written code. There's nothing special or rewarding about it.

-Dave