IMHO - Fundamentally Design Patterns are a Good Thing.

That being said - you need to understand the underlying philosophy that drove the creation of them in the first place.

There's not one person who's ever taken up programming that hasn't created a BALL OF MUD. The idea of design and software architecture in general is to make our lives easier.

That paper is a classic that's been quoted time & time again here. It explains the tribulations of attempting to use the design pattern philosophy in the real World.

My answer to you - if you want to call it that - is that you need to stop thinking of Design Patterns as a thing and absorb rather the essence of the underlying widom.

As you grow and learn as a software developer something interesting happens. You might in some ways say that you become less productive - in that you meditate over your code more before rendering it, and therefore write less code. But on the other hand, the code you write should be easier to maintain in the future. Futhermore, it should be less likely to be in need of being rewritten. It should incorporate all that you have learned from your experience & mistakes about how to save yourself a lot of work later by planning slightly more up front. It should reflect lofty goals like code reuse and component-ization.

But very much like Architecture in construction - the lay of the land dictates a lot.

I have embraced the concept of Open Standards wholeheartedly & as such became both a perl and a Java programmer. What I have noticed is that the languages themselves tend to drive you to think in certain ways. perl is a lot easier to hack in. If you want to you can usually create some THROWAWAY CODE in very few lines to get something working.

Java, in many ways, lends itself more to Architecture since it's not so easy to just create that "one-off proggy". It requires more effort, and as such, it sort of forces you to think before you code.

The upshot of this is that here at my job, I do my rapid prototyping in perl. But perl code for production use is frowned upon in this company due to maintainability issues. (We're not very replete with perl coders.)

So - to follow the process outlined in the article - I prototype for FUNCTION. Then I step back, look at what I've learned about the problem domain from the prototype, incorporate it into the design and then THROW THE CODE AWAY.

The next iteration produces a Java based project, along with corresponding UML and documentation.

Now I've noted that since we have a language boundary - it forces code to be discarded. That's a rather unique scenario however. Most companies don't operate this way. Also - I am a Maverick in that I insist on doing things the "right" way and openly and repeatedly attack my managers for attempting to make costly mistakes by 'cutting corners.' The simple fact that I take the time to write a prototype in perl at all goes directly against the grain of the culture here.

But then, as I've been quoted of saying in the past: Never Under Estimate the Power of What Works.

Note however, that taking that quote too literally can also lead to BIG BALLS OF MUD. As in when it is misinterpreted as "If it ain't broke, don't fix it."

Caveat Emptor!

20060928 Update: Replaces heretical usage of 'PERL' with 'perl'.