Re^4: Legacy Code: "Dominoes = Bad"

[armstd]

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

[JavaFan]

"Does the job". Requirements always change.

Yeah, but you either know what's going to change (and then do it right the first time), or you don't (and then, how do you anticipate?)

Maintainability lends agility to code

Eh, no. That's quite the opposite. Doing stuff now that isn't required is not agile. It's overhead. From The Agile Manifesto: Simplicity--the art of maximizing the amount of work not done--is essential. Anticipating to unknown future requirements does not lead to simpler code. Nor to less amount of work now.

Only maintainable, flexible code has any chance at all of being delivered on time while requirements keep changing.

Wait. By doing more work now, it's going to be finished sooner? How does that work? In the same way that paying more taxes increases my spending power?

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.

You got any data to back that up? Basically, you are saying it's impossible to write code that's fast enough, while it's not maintainable. So, code that's running fast enough, but of which the sources get lost (a real downer on its maintainability) suddenly slows down?

Poorly written code is just poorly written code.

Sure. "X == X" statements (even if one does rephrase the second X -- which you don't even bother to) are known as tautologies. They are a rhetoric device, and actually contribute nothing to the discussion.

[armstd]

The assertion that writing maintainable code implies more work is a falacy. It only implies different work, not more work.

Maintainability does not imply anticipating all future requirements either. It only implies anticipating that requirements will change, and therefore the code already developed will need to change as well.

You cite the Agile Manifesto, but miss that the basic definition of agility is ability to change (direction, speed, etc). The basic definition of maintenance (bugfix, enhancement) is change. Agility is maintainability.

The Agile Manifesto also says "Continuous attention to technical excellence and good design enhances agility."

The most common aspect of non-maintainable code that you'll find is poor design.

Good design will breed better code reuse, higher cohesion, and looser coupling. All of these are also fundamentals of maintainability.

Maintainable code is less work, not more. Its different work, requiring design expertise. Expertise that not all programmers have, and some programmers just develop naturally, and don't even realize they're doing so. For programmers without design expertise, talent, or aesthetic, yes maintainability is a lot of hard work, perhaps of questionable value. The Dunning–Kruger effect in action.

[JavaFan]

The assertion that writing maintainable code implies more work is a falacy. It only implies different work, not more work.

So, code that isn't written to be maintainable actually requires an additional effort? Curious. Can you elaborate, with some non-trivial examples? For instance, show me a method that does something non-trivial in the simplest possible way, then a maintainable version of it, and then show that it required no more work to write.

You cite the Agile Manifesto, but miss that the basic definition of agility is ability to change (direction, speed, etc).

Ditching, rewrite, copy-paste-and-change-one-line are all change as well. It's usually not what people consider "maintainable".

The most common aspect of non-maintainable code that you'll find is poor design.

Ah, yes, "poor design". What is poor design? More often than not people say "poor design" but they mean "I would have done it differently", or "I'm not smart enough to understand it". It's highly subjective.

Maintainable code is less work, not more.

I'm calling your bluff. Show it.