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

[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.

[Boldra]

Could it be that monks of your experience will see almost any example as trivial, because it's something you've been doing for years?

If not, what about CGI.pm? Would you agree that using CGI.pm is less effort and more maintainable? I posit that this is a non-trivial example because it is so frequent (still!), particularly roll-your-own query-string parsing.

How about descriptive varible names? One might argue that typing $target_hostname is more physical effort than $th, but descriptive hostnames can reduce cognitive effort, and if you know your way around your editor, the physical difference can be minimal.

[JavaFan]

Would you agree that using CGI.pm is less effort and more maintainable? I posit that this is a non-trivial example because it is so frequent (still!), particularly roll-your-own query-string parsing.

Using CGI.pm or not is about code reuse, not maintainability. But say I had handrolled my own CGI parsing, and for whatever new requirement, I now have the need to separate arguments not only by '&' and ';', but also by '-'. What do you think would be easier to do, change the code I wrote myself, or code that someone else wrote, and which doesn't live in my source control, but instead is maintained by the system wide packaging system, as it's third party software? (Note that I almost always would use CGI.pm if the alternative was writing it myself, but not for maintainability reasons - because code reuse makes I can deliver faster).

Could it be that monks of your experience will see almost any example as trivial, because it's something you've been doing for years

There's a lot that's not trivial. But I do mean a real function (or module) that does something - not a fragment like variable names. I'm asking for two implementations of the same functionality: one written in the simplest way, doing nothing more than required, and one written in the maintainable way, and then to show the latter did not take more effort to write than the former. (And with more effort, I do not mean the number of characters - typing '$target_hostname' or '$th' takes the same effort - effort is much more than the physical act of depressing and releasing keys; thinking what to write is effort; testing your code is effort; merging it into existing code may be an effort, etc)

[armstd]

Quality of design that adheres to principles is not subjective. It can be measured against those principles. Good design is based on analysis.

Yes, copy-paste is an example of change, and its not considered an "as" maintainable approach as reusing code, in the general case. Maintainability, like all abilities, is measured on a scale, not in black and white.