Design patterns are good, but complex. Should we use them in small projects? Implementing design patterns needs more sophisticated developers, which in turn raises project costs. On the other hand, they make code neat and clean. Are they necessary for small projects?

Update: Should we insist on using design patterns when the team is not efficient at working with them?

  • 27
    How can code that is "neat and clean" be more complex than code that isn't? Commented Jul 25, 2011 at 13:44
  • 12
    Don't make me link to this again: programmers.stackexchange.com/questions/70877/…
    – pdr
    Commented Jul 25, 2011 at 13:57
  • 11
    Design patterns are a transient artifact; that is, they show up in good design. You don't choose to use design patterns in one project and not in another. It is highly likely that a good design will display several well-known patterns.
    – Michael K
    Commented Jul 25, 2011 at 13:57
  • 5
    "Pneumatic drills are good, but complex. Should I use them in hanging pictures on my wall?" Do you have problems that can be solved with design patterns? If so, use them. If not, why are you even considering using solutions to problems that you don't have?
    – Ant
    Commented Jul 25, 2011 at 14:08
  • 2
    Does it require more sophisticated developers? Or does it require the baseline for what a developer should be capable of? Commented Jul 26, 2011 at 1:55

10 Answers 10


Design patterns are good, but complex.

This is a false assumption. Design Patterns are meant to strip complexity off existing code and to aid communication between developers. When Design Patterns introduce a higher grade of complexity, then they are misused.

Implementing design patters need more sophisticated developers and which in turn raises project costs.

This is also a false assumption. Any developer should strive for a minimum amount of complexity in his code. A good developer is well worth his money as the maintenance and extensibility costs decrease.

Are they necessary for small projects?

They are necessary when they help making the code more expressive and less complex. This is independent of project size. A good developer (tm) will not overengineer and use them when appropriate.

  • In addition, patterns in software tend to emerge when you attempt to refactor code to remove duplication. The trick is to recognize from the outset when certain patterns will be more useful than others, to save yourself needing to apply a major refactoring effort once the program has become large and perhaps complex. This is something that usually emerges with experience and time, but you can get a bit of a jump start by learning a few key patterns to begin with, and applying them when it is appropriate.
    – S.Robins
    Commented Jan 5, 2012 at 2:29
  • +1 for When Design Patterns introduce a higher grade of complexity, then they are misused. You should refactor your code towards a design pattern if it makes code changes easier and not the other way; where you plan for which pattern to use before knowing all specification changes. It is the same as looking into a glass ball (or predicting weather). It is better to design and refactor on what you know changes often, so that in the future changes are easier to deal with, and usually implement a design pattern along the way.
    – Spoike
    Commented Jan 5, 2012 at 10:20
  • I upvoted this as soon as I read Design Patterns are meant to strip complexity off existing code.
    – karthik
    Commented Sep 2, 2015 at 11:11

First of all, I will point out a great post elsewhere on programmers.stackoverflow.com: Design Patterns are for Communication. First and foremost they simply give developers a common language to speak about typical design/code artifacts that emerge from any design effort.

Onto the specifics of your question:

  • Design patterns are good: False assumption. Design patterns are neutral, some of them are less applicable than others and some are IMHO almost antipatterns in their own right (singleton)
  • Design patterns are complex: False assumption. Some design patterns are actually very simple, such as the template method pattern. Some are very complex, such as the visitor pattern. On average the simple patterns have more uses than the complex ones.
  • Should we use them in small projects? How small is small? Again IMHO the project would have to be extremely small to be well-designed and yet not include any recognizable design pattern. It might not include many, and will almost certainly skip some of the more complex structural or behavioral patterns such as visitor or chain of responsibility.
  • Implementing design patterns needs more sophisticated developers: partially true for the more complex patterns - but absolutely not for all patterns, and even more so for the types of patterns you are likely to put to good use in smaller projects
  • Raises project costs: categorically untrue if patterns are applied correctly. What may raise your project cost is lack of design, bad design, or wrongly/overly applied design patterns.
  • They make code neat and clean: all the best code as is neat and clean as it could possibly be made, this is not exclusive to the intentional application of design patterns.
  • Are they necessary for small projects: That depends on your project. If you can get away with code that fulfills its purpose but is very hard to maintain, that's fine. However if maintenance is likely (and it's nearly a certainty in all projects I've worked on) then the cost you save up front by not considering patterns or design as a whole will be paid back quite quickly in extra pain and duration during maintenance.

Falcon's answer is right, but I also wanted to add with additional information.

I recently learned (within the year - year-and-a-half) design patterns. At first, they became my "golden" hammer to all problems. I've just recently been realizing that I've been over-engineering a lot of the applications I've been developing. Recently, I was tasked to add additional functionality to a piece of software that I wrote, but when I looked at it, I cringed at the complexity I made it become. It was because at the time, I was in my height of design pattern euphoria and was making reasons to use my new-found knowledge. This is not the way it should have been approached. Now I end up designing my projects with simplicity in mind, more-or-less ignoring design patterns unless there is a very clear reason to bring them in. This usually comes up during the re-factoring process (at least for me).

Design patterns also allow developers to share a common language. When every developer knows the language, you can explain large sections of code very simply.

  • 4
    Almost every developer goes through this phase. This kind of software is a pain to maintain - and often people don't even know how - creating an even bigger mess.
    – sylvanaar
    Commented May 5, 2012 at 15:03

You are always using some sort of pattern. The only distinction is whether your pattern is as simple as possible or not. Code behind spaghetti and meatball code follows a pattern, it just happens to be a horribly difficult to understand pattern, because it puts everything in one place (who wants to work with code that contains SQL snippets, UI manipulations, and business logic all in one method). Remember, any idiot can write a piece of software that is horribly designed, but only a genius (probably an expensive one) can go back and safely fix that software later.

To answer a specific part of your question:

Implementing design patters need more sophisticated developers and which in turn raises project costs.

I think that you are misunderstanding what good design is. Think about this; Is it easier to understand an algorithm with 5 deep loop nesting or one with 2 deep loop nesting? Which would be the cheaper choice? The 2 deep choice is easier to read, write, maintain, and understand. So, why then are you trying to justify the 5 deep loop? The so-called "design pattern" is the simpler pattern every time, by definition. If your developers cannot write well designed software (aka: the more profitable kind), then you need to find developers who can understand programming well enough to make basic design decisions.


It depends not on the size of your project but on what problem you are trying to solve. Employing a design pattern for the sake of using it, is a bad bad thing, whether it is small/medium/big project. On the other hand, if by implementing a design pattern, you address a particular problem, then that is the right attitude and cool thing, irrespective of the project size. It is the intent that is important.


You should always be using design patterns, if only because you're a good programmer. You shouldn't be setting out to use them, however. If your design is sound, it is likely you will have used several design patterns (conversely, if your design is poor, you may start to recognise anti-patterns). I reject your assertion that design patterns are complex. Shoehorning them in unnecessarily will be complex, but using them correctly - i.e. as convenient handles for communicating parts of a design, and analysing their strengths and weaknesses - is not.

  • A reason for the downvote would be most welcome.
    – Scott
    Commented Jul 25, 2011 at 18:00

Think of design patterns as the common vocabulary for developers and software designers. Imagine a developer telling you

I have kept the constructor of my connection class as private and has instead given a public getInstance method where i have put a check that no more then N connections can be made.

instead of

My connection class is singleton with max N instances allowed

second line is less then 1/3rd of the first. Imagine the words you will save when you will use patterns like Factory.


I was going to comment on Falcon's excellent answer, but had too much to say to use a comment.

 Design patterns are good, but complex.

As other have noted, well written code will use design patterns, even if not intentionally implemented. Design patterns are observed, not invented. The simpler the design patterns tend to fit more cases.

The complex design patters are solutions to complex problems. It is often better to use the appropriate design pattern than to invent your own complex solution.

Shoehorning a problem into a design pattern in an anti-pattern. If the pattern doesn't fit the problem it shouldn't be used.

Implementing design patterns need more sophisticated developers 
and which in turn raises project costs. 

More sophisticated developers may come at a higher salary. However, they should come with higher productivity. There has been research showing huge productivity differences between programmers. Would you pay 50 percent more from someone four or five times as productive?

More sophisticated developers are less likely to introduce costly bugs into your software. This will reduce testing costs in addition decreasing rework to remove bugs.

Their code will usually be easier and cheaper to maintain in cases where bugs are found, or functionality needs to be extended.

On the other hand, they make code neat and clean.

Design patterns are one of several tools which will make your code neat and clean. They also provide proven solutions to common problems. There will be plenty of opportunity on most projects to use inventiveness on problems that don't fit well known design patterns.


Just to be pedantic, while recognizing Design Patterns does make it easier to understand what code does, the patterns themselves don't "make code neat and clean". It's more likely that patterns will make code messier and therefore harder to understand if they are implemented with little thought or understanding as to how to apply them.

Patterns aren't a silver bullet. They won't solve your problems for you, and worrying to much about whether you are using the "right pattern", or whether or not you can remember every single pattern in the GoF book won't make you a better programmer. On the other hand, understanding the language of Patterns will allow you to more clearly articulate ideas and designs in a meaningful way.

Design Patterns are merely tools which allow you to define and solve problems within the context of your code. If you try and use a lot of patterns simply because you think you need to be using patterns, you will end up heavily over-engineering relatively simple problems. For example, you could introduce a fully fledged Observer pattern for each event you raise in your code, but if your code is the only thing that will trigger those events, and if the events are expected to trigger only a single handler, then you don't need to create Observers to do the job, whereas assigning a simple function pointer to a property and the code to trigger it will probably do just as well. If you think you "might" need your Observer in the future, then it only "might" be worth the effort to engineer it. You risk future-proofing your code without really understanding if it will be worth the up front cost, and the result is often going to turn out to be like gold-plating when a splash of yellow paint would have been more appropriate.

Patterns often solve very specific problems, and they are just as often misused simply because they are a close yet imperfect fit for the problem at hand. Sometimes it can be better to see a pattern emerge from the code, and use your knowledge of patterns to help guide you to a better understanding about how to approach solving the problem. It may be at times that a pattern will do the job exactly, yet at other times you are better off taking the ideas behind a pattern, but implementing a modified version of the pattern to solve your particular problem.

All of this is would seem to indicate that the Language of Patterns is probably a more important tool to the developer than the individual patterns themselves.


A basic understanding and recognition of standard creational, behavioral, and structural design patterns can only increase a developer's understanding of OOD and gives them the ability to communicate complex concepts with less words.

Also, knowledge of concurrency patterns can make life easier when dealing with threaded execution. Easier is not harder!

Understanding patterns also gives developers a toolbox of ready-made solutions to very common software design problems. I would recommend instead of thinking of patterns as a skill to be used or not used, think of them as an advantage any developer should exploit.


Not the answer you're looking for? Browse other questions tagged or ask your own question.