Big Ball of Mud

This paper definitely is the most interesting of the papers I have read so far in this class which described real world situations of the software field and also seems like very straight talk on how they emerged and what we can do about it. I like reading it and also it has nice relevant pictures with each main topic.

Software field has the notion of architecture is luxury or Architecture is a long-term concern? Can a building construction be started without blue prints of the architecture of the building? Can a person who just knows how to put walls together can start building a house without having the architecture of the house in hand? I am guessing the root cause for this style of thinking in software field is due to ignoring this is also engineering.

Big Ball of Mud - big, ugly systems emerge from throw-away prototypes and quick-and-dirty code that was intended to be used only once and then discarded. However, such code often takes on a life of its own, despite casual structure and poor or non-existent documentation. It works, so why fix it?

One of mud's most effective enemies is sunshine. Subjecting convoluted code to scrutiny can set the stage for its refactoring, repair, and rehabilitation. Code reviews are one mechanism one can use to expose code to daylight.

Throw away code – created for immediate fix for a small problem, or a quick prototype or proof of concept but emerges into actual project. I like the examples presented to show most of us include our experiments in the actual code.

When you build a prototype, there is always the risk that someone will say "that's good enough, ship it". One way to minimize the risk of a prototype being put into production is to write the prototype in using a language or tool that you couldn't possibly use for a production version of your product.

Piecemeal Growth - Master plans are often rigid, misguided and out of date. Users’ needs change with time. Incrementally address forces that encourage change and growth. Allow opportunities for growth to be exploited locally, as they occur refactor unrelentingly.

Keep it working – Maintenance needs have accumulated, but an overhaul is unwise, since you might break the system. Therefore, do what it takes to maintain the software and keep it going. Keep it working.

Layers - Different artifacts change at different rates. Therefore, factor your system so that artifacts that change at similar rates are together.

Sweeping it under the rug - Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control. Therefore, if you can’t easily make a mess go away, at least cordon it off. This restricts the disorder to a fixed area, keeps it out of sight, and can set the stage for additional refactoring.

Reconstruction - Your code has declined to the point where it is beyond repair, or even comprehension. Therefore, throw it away and start over.

I like this from the paper –

Kent Beck has observed that the way to build software is to: Make it work. Make it right. Make it fast [Beck 1997]. "Make it work" means that we should focus on functionality up-front, and get something running. "Make it right" means that we should concern ourselves with how to structure the system only after we’ve figured out the pieces we need to solve the problem in the first place. "Make it fast" means that we should be concerned about optimizing performance only after we’ve learned how to solve the problem, and after we’ve discerned an architecture to elegantly encompass this functionality. Once all this has been done, one can consider how to make it cheap.