8

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.

Improve this question
2
  • 3
    "Once [...] you have plenty of time for the next release..." - isn't this like saying "as soon as hell freezes over..."? – nikie Jul 22 '11 at 20:45
  • 1
    Sounds like red, green, refactor. – Job Jul 23 '11 at 16:38

11 Answers 11

Active Oldest Votes
31

It is a lot more work and programming overhead to get it right the first time and within time frame.

That's false.

Without the benefit of someone having already thought through the design pattern, and explaining it and documenting it, it would be twice as hard.

A design pattern simplifies all the thinking and wondering and deciding.

You don't have to invent something new. You can use something that's already well-understood by yourself and others.

Improve this answer
18
  • Probably you prefer to use a ready-made framework like MVVM Lite Toolkit or OpenRasta? – RPK Jul 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.Lott Jul 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. – unholysampler Jul 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.Lott Jul 22 '11 at 19:36
  • 2
    @Chad: "You can still write bad software using design patterns". Since it's universally true about every technology, it's a tautology. It's doesn't seem helpful to repeat it, since it's always true. – S.Lott Jul 22 '11 at 20:21
13

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.

Improve this answer
3
  • 3
    +1: "Design patterns allow you to think less." – S.Lott Jul 22 '11 at 20:21
  • 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. – RPK Jul 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. – Job Jul 23 '11 at 16:49
8

In my experience, quick & dirty is an oxymoron. Any time you might save by skimping on design is almost always consumed by extra debugging.

Improve this answer
4
  • 2
    +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
  • +1: "Quick and Dirty: right now" becomes "Slow and Dirty: long term", "Slow and Clean: right now" becomes "Quick and Clean: lon term" ;-) – umlcat Jul 23 '11 at 15:57
  • @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. – RPK Jul 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 Bielefeldt Jul 25 '11 at 15:07
4

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.

Improve this answer
1
  • Lol. That was well. – RPK Jul 22 '11 at 19:46
2

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.

Improve this answer
1
  • 1
    Yes. Even Transaction Script is a design pattern. Pattern naming just facilitates conversation. – pdr Jul 22 '11 at 20:22
2

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.

Improve this answer
2

It is not more work and overhead to get it right the first time.

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.

Improve this answer
2

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.

Improve this answer
1
  • 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. – RPK Jul 22 '11 at 20:56
2

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.

Improve this answer
1
  • 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 Mohr Jul 23 '11 at 23:11
1

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.

Improve this answer
2
  • 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 C Jul 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. – RPK Jul 24 '11 at 6:36
1

No. It seems to take time to apply best practices (Design Patterns, M.V.C., whetever) to a problem, and is not that I or other developers do not know well Design Patterns.

Some of these good practices, can be apply even if you are in a rush, but, a good system, takes time to design.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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