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?
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.
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:
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.
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.
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.
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.
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.
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.
