OP-ED: Do You Hear the Sirens' Song?, Page 2
Designing OO Models and Using Existing OO Models Are Vastly Different Skills
Remember at the beginning I said I might be wrong. (Heck, I could be nurts!) However, I seem to be the only one saying or writing this: Consuming OO and producing OO are too vastly different skills.
Anyone with an IQ northward of 115 can use objects written by an expert; it's always the same: Find class, declare class variable, create instance, call method, modify property, or attach event handler. That's pretty much it. Sure, it's hard for the average dinosaur to get the hang of and college students (even from Ivy League schools) have a tough time getting started, but once you get it, every class is basically the same. Producing these classes is something else altogether.
Consuming OO requires a basic knowledge of grammar and few discrete skills. Producing OO is as complex as the universe. Almost anything can be created and described. Knowing what to produce is significantly more challenging. Even brilliant people stink at this, sometimes.
You say, so what's the problem? The problem is that all of those smart programmers with IQs north of 115 are smart enough to think they can do anything, including design custom frameworks. Wrong! In twenty years, I personally know of less than a dozen people that are really producing OO, and I have heard and seen evidence of people who are so good at it, it's mind boggling. These people are rare. So, the problem is that we have people trying really hard to design classes without a lot of formal training or skill doing so. (Maybe this is why VB people feel so good. I think these folks focus on using someone else's OO and just getting the job done. It probably feels pretty good.)
Designing good OO requires lots of knowledge of patterns, refactoring, and modeling languages. It also requires some taste, a lot of organization skills, experience, training, and a lot of practice. Just learning to program and use frameworks (as big as .NET or J2EE) is a skill very few people can master.
Thus, to succeed, software projects of any size or complexity either need to commit to using whatever framework is provided and muddling through or hiring a real designer. (These folks are called architects.) For, to let just any programmer figure out what classes to add willy nilly is to court disaster.
A process that works for you is great. One single process won't work in all situations. Consecutive waterfall schedules look good on paper but in all fairness aren't realistic. Building the easy elements first usually means building things that are of little or no real value. OOP and UML don't guarantee anything, but I wouldn't do without them either, and producing and consuming OO are two vastly different skill sets. The reason so many projects are GUI-centric and done using point-and-click RAD programming is because designing frameworks (good classes) is very hard.
Avoid making these mistakes and it will help you succeed, but success is the good judgment of individuals and really just having people on your team who know how to deliver software.
Finally, sometimes I am accused if writing condescendingly. Although that is never my overt intent, it's probably just the way I come across. It's the way I was made by the Creator. Just remember I am not writing to you with condescension. You are smart, worthy, and intellectually stimulating. I am writing about the person who didn't read my articles or buy my books.
Gobble! Gobble! Gobble!
About the Author
Paul Kimmel is the VB Today columnist for www.codeguru.com and has written several books on object-oriented programming and .NET. Check out his upcoming book LINQ Unleashed for C# due in Spring 2008. You may contact him for technology questions at firstname.lastname@example.org.
If you are interested in joining or sponsoring a .NET Users Group, check out www.glugnet.org. Glugnet opened a users group branch in Flint, Michigan in August 2007. If you are interested in attending, check out the www.glugnet.org web site for updates.
Copyright © 2007 by Paul T. Kimmel. All Rights Reserved.