Big Ball of Mud

The Big Ball of Mud architecture is what many projects end up as - a bunch of code tangled together with no clear boundaries. This may happen over time as fixed are placed in the easiest place in the effort to get something together quickly.

The authors listed a couple of ways to prevent this that I agreed with - code reviews and refactoring. The problem with many products is that time is not budgeted for this as it may seem superfluous. The main benefit - lower maintenance costs over the long term - is deemed beneficial enough to risk delaying putting the product on the market. This may in fact be the case in which case the manager made the correct choice! If the product works to the customer's expectations, is needed immediately, and will not need much maintenance, the reviews and refactoring may be overkill. Not every architecture needs to be beautiful.

I have worked on code that was supposed to be throwaway code that ended up being used. Now if code is going on the shelf as as part of IRAD, I check that it is easy to understand and handles errors. Rapid prototyping may be needed some times to reduce risk during development, but time should be allotted for actual cleanup if the prototype is going to be used in the final project. Putting in the extra effort up front makes no sense in the cases where the prototype ends up being scrapped anyway.