Big Ball of Mud

The main focus on this article seems to be on the thing that a high energy electrical engineer once told me during my first internship: "Temporary fixes become permanent solutions".
In today's business climate with it's customer satisfaction focus means that there is often a large backlog of bug fixes and enhancement requests for a product team to deal with. And as soon as one batch is finished, not only is there the rest of the backlog that you have to worry about getting done, expect whatever it is you just made to generate even more work for you.

Since this cycle of business pressure -> code -> release -> business pressure is constantly pushing the code base managers need to plan in time every iteration (or some other static time splice) to allow their teams to go over and refactor the current code base. If this isn't built directly into the company's product timeline then the crush of that cycle will not allow for the time to do this to simply appear. And what is making this more difficult is that the business must weight this time against other development activities that could be going on, and proving to your business leads that this time is well spent may be very challenging.

The assumption that it costs more to build a system with a good, growable, maintainable architecture upfront is going to take a lot of time is absolutlely correct. If experience has taught me anything it's that getting architecture right the first time is almost impossible. And worse, a team may spend all its time trying to find the "perfect" architecture without ever actually moving on to building the product, which is worse than not even getting a product to market. This is also partially true because the Ball of Mud can arise out of many scenarios, so the product may have started out with a good, solid architecture, but maybe it was simply neglected, and an architecture cannot be better than a team's commitment to ensuring its continued appropriate use and application.

When I first read the quote "Make it work, make it right, make it fast" I interpreted "make it fast" to mean build the application quickly. In that case my response was the ever popular: "Choose any two". But since this quote is more about the goals of your development efforts, from the initial code, through the next refactors (focusing on performance last) I'm more of the feeling that more companies should take the time to allow the second of these steps to take place. I'm not sure I've ever seen or heard of an instance where a product was allowed to pass through all three of these steps.

"Sweeping it under the rug" is an unfortunate consequence of brain drain as people leave your products and you eventually lose all knowledge of what a specific subsystem and/or technology is actually doing in your product. As an engineer these black holes are dangerous, you only have the guarantee of your co-developers to go on that this section of code is producing the correct results, let alone that it isn't actually broken somewhere inside. This is a scary position for any business/product/developer to be in. Unfortunately, without a large expenditure of effort you are never going to recover that section of the code, and if your business hasn't put forth the effort to stop this drain from reaching this point I doubt they'll do much of anything at this point.