Big Ball of Mud

"If you think good architecture is expensive, try bad architecture." Yes, the initial cost may be cheaper, but the price is going to skyrocket when the constant maintenance headaches creep into reality. Maybe cutting corners wasn't such a good idea. You start getting upset customers due to lack of stability and usability followed by upset developers attempting to maintain the system. The customer is losing profit and developers are losing their minds. It is a win-win situation if you are trying bring a system to its demise, but not so good if trying to be successful.

Have you ever noticed the worse the looking the code the longer the shelf-life? Think about it. No one wants to touch the dingy spaghetti code because you will go in with a nice, clean white shirt and come out with sauce all over your body. You could possibly "sweep it under the rug" for the time being, but, eventually, you are going to have to get your hands dirty by either doing some major refactoring, isolation, or reconstruction.

After a system has failed to meet a deadline or fallen flat on its face during a demonstration to the customer, upper management takes the lack of architecture guidance to the extreme other enf o the spectrum. Do not try to correct failed design by doing a 180-degree turn to the rigid, totalitarian, top-down design with architects requiring every hair to be in its place before moving on to implementation. That could be a very costly and detrimental choice.

It is funny how a simple prototype can easily become the productized version of the software being delivered to the customer. There is a reason it is called throwaway code. It is ideal to completely toss the code away. This is especially true when the requirements of the customer change. Management believes the software can be modified with no penalty to future design even though the current architecture cannot fully support the customer's requirements. Too many developers start trying to "patch" the code in order to satisfy the need of the customer. The longer the patching goes, the harder it is going to be to refactor or reconstruct the architecture in the long run.