Good code is cheap code

I've started seeing design patterns in a vastly different light once I realised that, in PHP, all of the Abstract Factory pattern can be replaced by a simple:

    $instance = new $className();

amortize "cheap" over the expected lifetime of the code. If man hours to write is the primary criteria then you'll have an uncommented mess of crap. I doubt the author means for this to be taken to the extreme. It makes for a good sound bite, but there is no simple rule of thumb when deciding how much effort to allocate to various parts of a project.

He's right. Most of the expense in software development goes into bad code.

Consider: good code is less buggy, easier to debug when there is a problem, easier to maintain, easier to modify, easier to understand, etc. When devs work on good code it takes less effort and there are fewer problems so projects are done sooner. Good code is like a repellent for developer effort. Sometimes good code doesn't even need updating or maintenance, it just keeps working from version to version. In contrast, bad code is typically a time and effort sink. And because it's so difficult to work with, bad code typically doesn't improve in quality (merely in functionality) so it becomes more and more of an effort sink over time.

Time is money, developers spend more of their time mired in bad code, thus bad code is more expensive.

Full title: Good code is cheap code, provided you substitute the following non-standard definitions for "cheap" and "good".

How about instead, you simply say what you're saying, without forcing the rest of us to do algebra on the language:

"Maintainable code is brief" pretty much summarizes that entire article. Note, however, that if you'd used that as the title we wouldn't have needed all those paragraphs of definitions.

What has been helping me out is the phrase: "Code that cannot fail is infinitely easier to maintain then code that has many paths through it which might fail."

Murphy's law: "What can go wrong WILL go wrong". So go over every line of code and ask: "How might this function do something unintended?". If you find any answer to that question then you need to change how the function works until the answer is: "This function physically cannot do something unintended". If the hardware and compiler are working to specification then the ONLY path through this code is the correct way through (or a pretty exception/error that tells you what the programmer/user did wrong or what the hardware/compiler failure was).

For example: you have a function calculate() which takes a collection of Strings which represents items to process. The problem is that function foo() might run incorrectly and some String items may become invalid or incorrect. Then calculate() will make its best attempt, then calculate may throw an exception/error or worst of all, it may work. The solution here is to make it physically impossible for the items in the list to become invalid/wrong, don't use an array of String, use an array of class Student/Airplane/Book/ProcessItem which has a constructor which validates its own existence as soon as it is made, it will produce a runtime error (or better yet a compile time error) the instant the programmer/user made a mistake.

The millions of unintended paths through calculate() which may throw a cryptic runtime exception has been eliminated. Imagine how much easier it is to diagnose a "InputProcessItemException" than a cryptic off-by-one error inside calculate();