A Word on Patterns [Seeing the Light] : Blog : Intrepid Studios, Inc.

A Word on Patterns [Seeing the Light]

By Kamran Ayub, 8:10 PM on Thu Jun 11 2009 | 2 comments

When I started to teach myself .NET and programming, I think that I did a good job. I've been using .NET since 1.0 and have loved it ever since, with more powerful enhancements regularly released. I've used languages starting at HTML and ASP and to more 'modern' languages like C# and XHTML. I can program in a variety of different languages and environments, even dabbling in some C++.

But, there is a downside to learning on your own and that is that you lack the vocabulary to research effectively. If someone had told me to search for and learn patterns, I think I'd be a more robust, effective, and intelligent software architect/developer now. It wasn't my fault necessarily, how was I to know what the word "pattern" meant in software development. I may have seen it, in fact I know I saw it, but I never knew what it meant so ignored it. Funny thing, my dad gave me a book called Patterns of Enterprise Application Architecture by some guy named Martin Fowler maybe a year back. I maybe read the first few pages, got bored, and gave it back to him. Wow. I can't even believe I did that, from what I know now and who he is.

I don't think it's fair to say that I was a bad designer or developer because I didn't know patterns. I realize now, after learning more about them, that I was implementing my own shaky patterns without realizing what it meant. Of course, because of that, my implementations were not as flexible or robust as they would have been had I known how to properly create and envision them. I mean, Torrent Typhoon was one of my best tiered applications even though it may have included some business logic in the presentation layer. It automatically caught and logged errors, elegantly refraining from intimidating the user with scary error pages. It was also so robust, flexible, and accommodating that after refining some code, I hardly ever received error reports or bug reports (that it caught). I may not have known what "Business Objects" were, yet I made them. I may not have known what "Domain Driven Design" was, yet I even did that on my own (albeit less structured and "pure").

So here's my advice for .NET newbies or do-it-yourself developers: find someone who's either had formal experience or who has worked on real-world applications. I didn't even realize how much my dad worked with patterns until a few days ago when we got into a conversation about what I was studying.

My other piece of advice is to be careful. The excellent (and hilarious) book Head First sums it up: Don't succumb to Pattern Fever. Martin Fowler, the GoF, they're all still developers (smart ones, at that) and not Gods. Maybe a pattern is awesome, but you don't necessarily always need to use it, especially for small, single-user applications. It can also be really overwhelming, with so many developers giving their $0.02 on what to use and what not to use. Even I am still trying to wrap my head around the different patterns and when to use them. Sometimes not thinking about a pattern can result in a creative solution. I used an XML file to store regular expressions that mapped to rows of data from screen-scraped sites for Torrent Typhoon. To fix my results all I had to do was modify the regular expression in one file to conform to the external site's new HTML layout. The engine took care of parsing it and mapping it to data tables, is there a pattern for that? Maybe, but I didn't know that when I created it. I fancied myself pretty damn clever, mind you.

My last advice (to everyone) is to never think you know everything. Malcolm Gladwell's newest theory purports that it takes 10,000 hours to be considered an expert. That's a LOT of hours. I've been programming back-ends and designing front-ends for the past 9 years and I still don't consider myself to be at the advanced level, I consider myself to be at an intermediate level. I have no qualms with being wrong, I just love to learn new techniques and get advice. Even I get excited and make mistakes or use the wrong wording to describe something. We all do.

I highly recommend checking out the Design Pattern Framework 3.5 package for $99. It's a real help, especially for someone like me who knows how to code but isn't super familiar with patterns or how to implement them from "abstract" code samples that you so often find. It comes in both C# and VB.NET. Not only that but it goes hand-in-hand with Head First providing .NET implementations of the Java code samples and also presents Fowler's enterprise patterns, too. I just finished reading the 125-page PDF where it explains an entire real-world eCommerce application implementing real patterns in a useful and easy-to-understand way.

Books I recommend that I am currently reading are:

Comments

Zachary Johnson contributed about 9 months ago

Almost all of the gifted programmers I know are largely self taught, and that is exactly what makes them great programmers. That go-out-and-do-it-attitude results in that person trying out a lot of things and writing lot of code. And that writing a lot of code part is what makes the programmer great. Why? Because they'll have written a lot of *bad* code and learned from it.

The best definition of an expert is somebody who has made every possible mistake in a very narrow area of study. It is possible 10,000 hours may be a fair measure of how long it takes for a software developer to really make enough of the important mistakes. But really, that 10,000 number was just pulled out of somebody's ass.

There is of course value in books and formal education, both of which are excellent ways in which to give a programmer the language and common ground with which to talk to and work with other programmers. I honestly think that books and formal education are actually more valuable to the person who is previously self taught, because even though at times the information will seem redundant or like old hat, it is all of those past programming experiences that will put the information in lectures and books into context.

Software patterns don't do any good to somebody who doesn't understand when to use them (or more importantly when not to). And there isn't a pattern for every situation. You have to understand the underlying principles of the patterns so you can understand which ones to use, and also so you can still write good software when you have to invent the patterns on your own.

It isn't that your applications *needs* a "service layer." You just need to be sure your application meets service-level requirements like extensibility, scalability, maintainability, etc.

It isn't that your application *needs* to be Model-View-Controller. You just need to think about things like modularity. And separating your database from your GUI. Your presentation from your logic. Etc.

Really I think you've written a great post here. You cover the value of patterns. You give the caveat of "pattern fever." Perhaps the only point I am making is that the best software engineers and programmers don't necessarily know the name of every pattern, but they can tell you the usefulness and reasoning behind any pattern that you put in front of them.

Kamran Ayub contributed about 9 months ago

Thanks, Zach! I totally agree with you...

In the "formal" classes I had, none of the instructors talked about the philosophy of thinking and problem solving when creating a software, just how to do it. I had to teach myself how to think about a problem and then solve it. I agree that books are valuable there because they may open up roads you never knew were there... especially helpful for me, in that regard.

Add Your Comment

Bottom Navigation

Top Navigation

Latest Projects