The Price of Purity

By Allen Holub

February 1, 2005 —

I don’t believe that it’s reasonable to use Java as a procedural language solely to leverage its rich set of libraries. If you’re going to use Java, embrace the object-oriented paradigm. Unfortunately, not everyone agrees with me.

Most people who build “pure” OO systems notice an interesting paradox: Pure OO systems are simultaneously more complex to build and easier to maintain than hybrid procedural/OO systems. The complexity is just inherent in the language and the mechanisms of object orientation (like inheritance). The “pure” system is better organized than the hybrid, however, and that is reflected in easier maintenance. Hybrids tend to have all the complexity inherent in OO without any of its maintainability.

I guess my belief makes me a purist, but I think of it as pragmatism. I just got sick of rewriting hybrid systems once they hit maintenance (which happens five seconds after you write the first line of code). My experience notwithstanding, I often hear the word “pure” spoken with a sneer, as if it’s a bad thing. I’ve been told that in the real world, nobody has the luxury of “academic purity,” whatever that is. In reality, I don’t have the luxury of wasting time building, debugging or maintaining procedural systems written in Java. The pure systems go together faster, have fewer bugs, and are vastly easier to maintain.

Nonetheless, most Java shops don’t do anything like pure OO. In fact, many Java programmers don’t understand even the basic principles of OO design and programming. Moreover, many off-the-shelf tools encourage a procedural approach (Apache’s Struts open-source framework comes to mind). If you’re working this way, you won’t get most of the real benefits of OO, however.

Managers—even those who understand the benefits of OO—circle around the methodology like sharks who are wary of their prey. They want the advantages of an OO system but don’t know how to get them. For example, they pay for training but are unwilling to actually implement the things that their programmers learn.

The problem is rooted in the development process. Moving to OO is not just a matter of using a new language; it’s a fundamental change in the way you write software. All software shops have a development process, even if it’s an ad hoc one, and there are many support mechanisms for that process entrenched in the organization. If you change the way you write software, you have to change the organization to support the new way of doing things, and that level of change is scary.

I just had that reality driven home. Here’s what happened.

A client of mine (Bill Hamilton, at MTS Technologies in San Diego) recently wrote a letter of recommendation for a prospective client that I was courting. Bill’s letter cited the OO design and training work I had done for MTS; he wrote a thoughtful, six-page review of my work that I liked quite a bit (since it was pretty complimentary). The letter also described the pitfalls of moving from a seat-of-the-pants design environment to an OO one as well as my proclivities in the purist department, however. My immediate response was: “I hope this doesn’t scare my new customer away.” Judging by the deafening silence that ensued, my fears seem justified.

Bill’s e-mail comments about this situation were, I think, to the point:

“My theory is this: you desperately want to drain the swamp, thinking it will solve all your problems, but you’re afraid the alligators will still be there. What if I go through this training and my problems are still there or, worse yet, compounded? What if I go through this training and find out my staff isn’t capable of operating under a new paradigm? What if I go through with this training and find they understand it, but I don’t?! What if I go through this training and find out it will cost millions and take years to fully implement into the staff, the company, the legacy systems, the infrastructure? These are all questions that [the managers] should have had answered ahead of time. I propose this: until they’ve answered the above questions, they’re not ready.”

He went on: “I can see them saying, ‘Well, we tried Allen’s approach, but obviously his style didn’t work.’ They couldn’t distinguish between their follies and deviations from your training, so couldn’t accurately assess the value and benefit of it.”

All of the fears that Bill mentions can be addressed in reasonable ways, but I endorse the notion of thinking out the ramifications of a change in process before you go ahead with it. I believe this sort of change is usually for the better, even if it is difficult. I’ve occasionally worked for companies where change was not possible, however, and it’s better to identify potential difficulties at the outset of the process. z

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.

Share this link: http://www.sdtimes.com/link/28398

After the Launch, Microsoft Sets the Price Having released the long-awaited updates to its enterprise database and development environment, Microsoft last month also announced pricing for the...

WHAT PRICE PREVENTION? Michael Lutz’s recent Guest View ["Analyzers: What’s the Business Value?" Jan. 15] raises a very important issue, one...

Defect-Tracking Tools: Price Vs. Performance The days of the stand-alone defect-tracking system may be numbered. As software projects continue to become more complex, and as...

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST