I am wondering, in tight deadlines, who has time to implement design patterns? It is a lot more work and programming overhead to get it right the first time and within time frame. I know that it has long term advantages, but were you able to implement any design pattern correctly when the client is sitting on your head and pressure is growing.

I think once your first version is released and you have plenty of time for the next release, than you can think of improving code quality and manageability with design patterns.

Probably you prefer to use a ready-made framework like MVVM Lite Toolkit or OpenRasta?
–
RPKJul 22 '11 at 19:26

2

@RPK: No. Design patterns make programming easier by providing a way to understand a problem and a way to solve the problem. Frameworks happen to be built around design patterns, but don't matter. I use design patterns inside frameworks and outside frameworks all the time.
–
S.LottJul 22 '11 at 19:28

I think that comment was more about doing something quick and dirty for now rather than doing it the best way.
–
unholysamplerJul 22 '11 at 19:29

2

@RPK: "When we were not using them, were we unable to write better applications?" No. Today there are many programmers don't know a lot of design patterns and implement bad software slowly. When they learn design patterns, they write better software more quickly.
–
S.LottJul 22 '11 at 19:36

Design patterns allow you to think less. That is really the entire point. There is a bit of a false dichotemy implied in the question. It suggests that you either use design patterns, or you use no patterns at all. The real is choice is between using an established pattern or a home made pattern. Sometimes your design will be better than the reccommended approach, but...usually it will not be. Why go through all the work of solving a problem that has already been solved well. Your own half-baked version will hardly ever be as good, and you have to waste all that brainergy thinking it up.

Agreed. The home-made style with simple reuse capabilities worked well for me for years. Till date I found no problem in scaling and maintaining application. I definitely want to follow an established pattern, but again it requires me to be mature enough as the pattern. If you have a thorough understanding of an established pattern, the road is easy else you can't expect to deliver on time depending upon books and forums.
–
RPKJul 23 '11 at 5:24

Appropriate design patterns allow me to think less. Strangely, I have never needed to visit the internet to look up the name of a design patter that would be appropriate for my use. I just come up with a way to refactor code without knowing the names of the patterns that I just invoked. This is not so with data structures and algorithms. Re-inventing those would be very hard, and thus it makes sense to learn from others. Design patterns are mostly common sense. Many should be and some are part of a library or a language. Some design patterns arise due to a limitation of a typical OO language.
–
JobJul 23 '11 at 16:49

+1: Quick and Dirty is an Oxymoron, could not phrase it any shorter! I have seen too many people starting off implementing now. We are developers, and thus we write code, but it does not mean that all we do is typing on a keyboard. Thinking first is not a waste of time...
–
Matthieu M.Jul 23 '11 at 14:31

@Karl: I don't want to name few companies because the names are in Fortune 50. Recently an employee told me that companies are paying hefty price for poorly implemented patterns. It is just keep the app. running without thinking of future scaling benefits. The project has to be delivered before deadline and there is no time for improving quality.
–
RPKJul 24 '11 at 6:43

No one claims the mere use of design patterns ensures quality, but having the right design up front not only helps long term quality, it makes it easier to get the first version out the door faster. If fancy design patterns are getting in the way of that, you're doing it wrong.
–
Karl BielefeldtJul 25 '11 at 15:07

Don't commit to a deadline that doesn't give you enough time to do things right. You've got to pay back the technical debt eventually, and the more code you have in place before you start re-factoring things into a sane design, the harder it will be. That means even MORE work and programming overhead.

The list of design patterns is very long (people like giving things names). Even if you are not putting thought into "Ok, here I am using _ here", the thing you are doing likely is a pattern that someone has named. The more you program, the more you will have an idea about how to do something and the less you will have to worry about what patterns you are using.

I think once your first version is released and you have plenty of
time for the next release, than you can think of improving code
quality and manageability with design patterns.

I share a similar situation. For maintenance of applications, there may be extensive refactoring required to make the design pattern worthwhile. If there is a big downtime around the corner then its best to put off until you have the time to fix the issue.

Especially if the client is demanding a product yesterday. The software quality triangle exists whether you acknowledge it or are aware of it. "Getting it right the first time" often requires heavy upfront planning including good requirements and low scope creep. This means the client has to be willing to actively participate in the shared success of the project.

Also keep in mind that OO 101 requires one to build a section until it is requirements complete. THEN refactor, otherwise you are just spinning your wheels.

If it is not broken chances are it wont get fixed. And not right does not neccessarily mean broken. There will always be something else that needs done. So you will spend far more time supporting it and less time able to correct it or create something new.

Not only that doing it right does not take more time than doing it wrong. It may appear in the short term like you are not meeting arbatrary deadlines or milestones. But in the end it all comes together in about the same amount of time. But the quality of the first QA Release will far surpass the first qa release of the seat of the pants build. This will reduce the rework prior to release. In the end doing it right doesnt just tie, it wins every time.

Chances are, if it takes you longer to implement a design pattern, then the pattern you're trying to use isn't a good fit for the problem you're trying to solve. You don't get "bonus points" in your next code review for implementing a new pattern, the point is to be able to more easily identify proven ways of solving common issues. Design patterns are a way for people to share an approach to these problems, and be able to talk about it in common terms.

The only Bonus Point is that I always get it right the second time. This is because after a few months of deployment, client and me both realize what we want. Many will fume with this dumbness but it is like that.
–
RPKJul 22 '11 at 20:56

It is very likely that you are already using design patterns, they are just a formal classification for commonly recurring architectural concepts.

To use a construction analogy - where you might refer to a certain part of your building as "the part that keeps the rain out and the heat in", someone versed in building would just call that part "the roof". There's no disadvantage that I can see in implementing a "roof" on a house as opposed to implementing a "part that keeps the rain out and the heat in"

The main overhead is figuring out what design patterns fit where, since they are often quite abstract when seen out of context. You are almost certainly using Facade/Factory unless you're writing procedural. I found Observer, Strategy and Factory the easiest to get my head round starting out.

I like this interpretation. "Design patterns" have become a bit of an HR catchphrase that often just mean "a problem someone has already solved". The process of identifying if your solution benefits from applying a design pattern is valuable simply because it forces you to think about your problem in abstract terms. If you don't do this, it's verybpossible you don't actually understand the problem you've been asked to solve.
–
Stefan MohrJul 23 '11 at 23:11

As others have noted, getting it right the first time is of course cheapest. But i would also point out that any programming construct whatsoever falls somewhere on the spectrum of pattern-anti pattern. You're either implementing something in an orderly way or not; 'goto' infested code is following a pattern, it's just something that was recognized early on as potentially harmful. But note that all code boils down to jumps and branches at some point in the compilation cycle. There's nothing inherently wrong with jumping: it just ends up making larger projects more difficult to understand.

It is easy to get misled by patterns that appear trivial for simple use cases. As soon as you start needing more flexibility, most brittle patterns will degenerate into anti patterns. So my rule is to only write code I can understand and have a reasonable chance of debugging. If I decide to apply a clever pattern blindly, I have to be at least as clever as the pattern-code in order to debug it. So the key is just making sure you're isolating and utilizing patterns that apply specifically to your problem directly, that you're approaching the problem at the proper level of abstraction, and that you can understand and debug every line in your code.

One key here is striking the right balance between short- and long-term requirements. Keep in mind that writing good code quickly is something that starting from well-understood patterns can certainly assist in -- spaghetti code may seem faster, especially at first. But you will quickly see the limitations of anti patterns in any larger project, where decomposability, modularity, etc., become incredibly important.

I am going against the grain and say that they can help but most often hurt when under the circumstances you describe.

They help IF you are very familiar with them AND (you have good test coverage of all the parts that will be effective OR this is green field coding).

But, really, if you are asking this question then you either
A. Don't use the patterns as a natural way of doing things (because if you did you wouldn't think to ask, you would just do it without thinking)
OR
B. The code is so incompatible to the implementation of the pattern in the amount allotted that it is simply unrealistic to use the pattern.

The code is so incompatible to the implementation of the pattern If that's the case, then it's either a poor choice of pattern, or the code isn't solving the problem. You pick a pattern that solves the problem you're facing, not try to shoe-horn as many patterns as you can into a project for bragging rights!
–
Joel CJul 23 '11 at 4:07

The answer is C: I am still not confident and sound enough to implement them in a production project. As I wrote somewhere above, a home-made recipe is just working fine and there have never been any issue with scaling and re-usability. I definitely want to follow industry standards but not without thorough grasp of the subject.
–
RPKJul 24 '11 at 6:36