when I use design patterns in a small project, can that be considered an "overkill"?

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

It's about scale really. In larger projects you'll save time by doing the "boring" analysis, whereas on smaller ones you could actually extend the overall time. (Having said that, even the smallest task will benefit from some upfront thinking/doodling time)

Either way, I'd say don't bend your approach simply to accomodate patterns. They are like any other tool, and not some panacea whose inclusion will guarantee success.

Answer 2

You don't understand the meaning of a "design pattern" - it simply means something that's been done before that someone has perhaps put a name to. So for example, sorting an array and then using binary search on it is a design pattern - I must have used it hundreds of times in the past, and when I'm designing a small application that needs a search, it's one of the first things I think of. Such patterns are used by experienced programmers on both the smallest projects, and on the largest.

Answer 3

My experience has been that 90% of the time, jumping straight to code is a bad idea. Even on small projects, I end up wasting time because we implemented things incorrectly or didn't plan well enough for XYZ failure case. Coding without a plan is usually a bad idea.

I'm not saying you have to use UML or write a 300 page spec, but I find that use cases and error conditions are critical to plan out before writing any code.

When it comes to design patterns, the answer is yes take the time to think about them and diagram out where they can be useful... and where they are not useful. For a small project a week might be overkill but some planning will produce better code which is easier to maintain and is more useful in the long run.

Answer 4

Design patterns are not something you "decide to use". They come naturally, if you are experienced enough to see them. And they are not overhead - the amount of code to add is rather small.

Answer 5

The old saying goes that "if you have a hammer, then everything starts to look like a nail", meaning that if you know of design patterns, you keep trying to fit them in, even when you might not need them. Keep in mind, that in terms of coding design patters, singleton, factory, etc... are very lightweight in terms of their time to implement and shouldn't really be anything to mention to management.

However, analysis and "diagramming" as you put it, is very valuable. If its a small project, then it will take a small amount of time, nothing to worry about. Often, a quick analysis and "pre-thought" will highlight any issues earlier than while simply cutting code.

Answer 6

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).

Answer 7

Bozho said how it should be ... but in the hands of most people, design patterns turn into hammers in search for a nail ... in the end they solve problems such as closing a bottle of coke by putting nails into the screw top, so they have something to hammer on ... in the end, the actual problem is not solved, because although the screw top is now again fixed to the bottle, the bottle still alows its content to escape ...

design patterns are not to be thought of as the components to build a design from ... design patterns are solutions to common problems that emerge within the process of design ...

your question seems to rather be, whether or not you should take the time to design your software, or whether you should just try to deliver software that seems to solve the problem, as fast as you can ... you shouldn't do the latter ... sometimes it is sufficient to actually design on the fly and this is ok, as long as:

• you have figured out a way to keep dependancy low and interfaces small
• you have a consistent way how responsibility is distributed (and hopefully it's not the usage of a god object)
• you produce readable code with sensible naming
• you provide comments about what you did, why you did it and which parts seem to need review

once you take these habits, you are not really slower, but your software turns much more maintainable ... also, for small problems, it sometimes makes more sense to just try to solve them through implementation and then learn from what went wrong and reimplement them with that knowledge ... it may turn out to be faster and includes a learning process, unlike top-down approaches ...

if you succeed in actually dividing a project into such independant small problems and can define interfaces how to access functionality provided by the respective solutions, then your design is actually perfect and you needn't get into details further ...

greetz

back2dos