Question

I have seen programmers code way too fast in the classic procedural way. They can code authentication systems in a few hours. Nice, neat, and most notably…delivered “lightning” fast.

But, a major flaw is that whenever a change occurs, we had to go through the core code to fix things.

So I thought of using design patterns; but that would mean adding a really big thing to ow we handle things: we had to do systems analysis via diagrams, so we can effectively apply design patterns like observer and composite, decorator, factory, singleton…etc…and our bosses would definitely not like to hear that we “need additional time” when everything we have done the procedural way went a hell lot faster (not to mention we can always modify the core).

With small projects like, say, a hotel listing site…or a product gallery site(with a whle lot of features), would the “additional time” to do diagramming be worth it?

A side question: did you ever have to change things from when your group just jumped straight to programming to having to dedicate a week for “boring” diagramming and analysis?

Answer 1

Your question is wrongly worded. You’re not asking about design patterns, you’re asking about formal design, producing design documents before starting to code. But again, you can have good design without having explicit design documents, and you can have design documents without having to do them before you start coding. Generally:

• If you find that you’re producing code that is hard to maintain, your design is probably bad
• Spending some thoughts on design before starting to code can lead to better design
• Writing explicit design documents mainly helps coordinating larger teams on larger problems and is typical for “heavy” processes – you seem to be thinking about that kind of thing when you talk about “overkill”
• An alternative (that often yields better results than doing a lot of upfront desing) is to start coding and develop the design along with the code, refactoring as you go whenever you notice a flaw in your current design. This kind of thing is known as an “agile process”
• But that still means you have to spend time thiking about and improving the design rather than coding exclusively towards required functionality – but it will lead to much better code that containes fewer bugs and can be changed more easily and with fewer side effects.
• And you still want to have some sort of documentation of the design to help people understand your code better (and even the person who wrote the code often needs that help when they come back to it for a bugfix 6 monts later). This doesn’t have to be fancy; a sentence or two explaining what each major unit of code (e.g. classes) does, and an overview document that gives you a broad idea of how it all fits together (this may contain an UML diagram or two).