|Perl: the Markov chain saw|
Re^4: Legacy Code: "Dominoes = Bad"by armstd (Friar)
|on Apr 29, 2011 at 02:59 UTC||Need Help??|
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.