my first exposure to "Design Patterns"

After writing software on my own for almost 15 years, including dozens of applications that served tens of thousands of fortune 500 users and served up thousands of hours of content, along with user/content management and access control, content authoring tools and countless UI components, assessments, and API based system specifications...I've finally gotten to a place in my career where I've been introduced to the concept of Design Patterns.

Being largely self taught and mentored by self taught engineers, I eventually came up with methodologies and best practices that helped me produce applications quickly and cost-effectively while maintaining a high degree of reusability and flexibility. My software continues to generate revenue for past and current clients, and has invariably been successful in delivering its stated goals.

My latest work opportunity has put me in a position to work with some engineers with more formalized training than I have had, and I've observed that came with the benefit of the collective knowledge and experience of engineers across a variety of disciplines that I never really had, being almost always the "lone engineer" on projects, or being fairly separated from my team of engineers to focus on the business / strategic side of technology. My new team represents the best talent Ive worked with yet, so I wanted to take advantage of the opportunity and see what I could learn from them. The first thing they pointed me to was "Design Patterns".

In various capacities I had heard the terms "Model-View-Controller", "Singleton", and of course "prototype" bandied about, but was more busy writing code than thinking of how to describe what I was doing via inherent common sense. It always made sense to me to have major components of my systems decoupled, and my circumstances would have described this as Data/API/UI. In my way of thinking, all my apps were driven by some kind of data/content in one bucket, an API that knew where the content/data was and could be queried by any UI engine. I'd been using this approach long before "cloud server" came along, really since my first app, the "auto player software" followed by my various flash applications.  Until I read about MVC, I practically felt like I invented it.  (thats what happens when one essentially lives under a rock)

I felt this concept applied to every kind of software I built, from the big enterprise apps and systems I designed, to the smallest 2 minute entertainment interaction I built.  There was always data, content, an interface, and view.    I'm not sure how that precisely maps to "Model View Controller" but I'm not too concerned about it, because it always worked.  By the end of developing hundreds of apps using a very specific set of best practices and designs, I had the system down to the point of being incredibly efficient and reliable, and exceptionally flexible.  Once others learned my system they often copied and adapted it for their own use.

So as I begin to explore MVC and other design patterns, I am feeling a strong sense of vindication.  That while I've been working away in a "dark cell all alone"  I ultimately came to the same logical conclusions as the rest of the software community...only I use a different nomenclature.

To me, and most "old guys" I know, it doesn't really matter how you build something.  Its whether or not it does the job and didn't cost too much in time/money/effort.  If you build something too hastily it will cost you down the road in maintenance and fixes.  If you build something too slowly, you'll end up making $0.02 an hour, and only 3 people on earth will appreciate the "elegance " of your work.

So this brings up an impression I'm getting now.  In reading "Head First Design Patterns" I get the distinct impression of an almost zealous "my way or the highway" sense that reminds me of a religious fervour.  They speak of their nomenclature as if its really the "only" enlightened approach to problem solving in OOP.   I have to agree that a common nomenclature is helpful in a situation where code needs to be shared across a group, and am more than happy to embrace a common lexicon organizationally to improve interoperability and communication between engineers.

That said, I have to agree with Steve McConnell who said


"Moreover, shifting the code too far forcing it to look like a standard pattern unnecessarily increases complexity."


This does not constitute a justification for "shutting down" a design pattern approach, but it is more cautionary in struggling to attain a perfect score among programming buddies could potentially cloud the primary goal of making software that works for the user on time and under budget.

So I'll continue to study design patterns and post here periodically as my learning increases on the topic.  So far just reading the terms and definitions has not only provided me with the feeling of "so that's what they call that thing Ive been doing for all these years", but also some of them provide ideas that will make my code more efficient, readable , and reusable going forward.

My next post will be on the flash IDE timeline based programming vs OOP and how they really aren't all that different, but it will relate to this one as a last word in that I'd go further to say that design patterns in OOP do not just apply to code written in standard scripts like AS3, C#, Java, Javascript etc., but also can apply to visual programming IDE's like the flash IDE, Authorware, Director, and customized frameworks.