Adopting OO
I’m writing this editorial in Ottawa, where I’m teaching a week-long OO-design workshop. (After some preliminaries, we spend three days actually taking a real design from requirements gathering through the UML-modeling stage). It’s a great way to learn the subject since you get hands-on experience actually doing it. This time, as is more than often the case, someone brought up the adoption issue: “This stuff is great, I really understand how doing all this will make me more productive, but how can I get my manager to go along?” This question is a tough one to answer in the general case, but I’ll give it a try.
In her Succeeding With Objects, Adel Goldberg says “Many people tell the story of the CEO of a company who bragged that his project was object oriented because it was written in C++. Many people don’t realize that this is a joke.” Simply writing a program in Java doesn’t make the program object oriented, though many managers don’t know it. (“Real programmers can write FORTRAN in any language.”) The fact is that OO is largely language independent. I’ve written OO systems in C (and once in assembly language). The ANSI C FILE is a perfectly good object, complete with constructor (fopen), destructor (fclose), and a set of methods (fread, fwrite, etc.). The internal implementation of the FILE class is completely hidden from the end user. OO languages such as Java make it easier to write OO systems simply because they support primitives that do a lot of work in the background that would otherwise have to be done by hand. You are simply not leveraging the power of Java if you are not using it to implement an OO design.
The only efficient way that I know to write an OO program is to go through a formal (or informal) process that includes the following activities: learning the problem domain, creating a problem definition in English by working collaboratively with an end user, identifying use cases and scenarios within those use cases and building an activity (or some form of workflow) diagram, building a dynamic model that shows the flow of messages through the system while some task is being performed, capturing information about the dynamic model in a static model, and then, at the end of all, coding. All of these activities can be done sequentially or concurrently, depending on your methodology of choice.
The design process is a lot of work (though it’s fun). I spend roughly 50% of a project in design, roughly 30% in coding and debugging, and the rest in miscellaneous tasks. Nonetheless, when compared to working procedurally, I get the program written in about half the time I used to, the program has dramatically fewer bugs, and the program is very usable. This reduction of both development time and bugs is commonplace when you “do it right.”
Let’s get back to our hapless manager, who equates productivity with lines of code produced per day. When you say that you need four to six months in design before, hapless managers will typically make two enormous mistakes: they will assume that the design process isn’t “work,” and they will mentally add the time spent in design to the time required to do the last project.
My experience, however, is that every hour I spend in design saves me three to four hours of coding/debugging. The time spent in design is more than made up by the time saved in coding. The real mental estimate when you mix design into the equation is that, compared to the prior projects, well-done OO systems will be developed in roughly half the time as the prior projects, and it will have at least half the bugs, coming out of the gate.
But how do you get this notion across? Simply teaching the programmers OO is in itself not sufficient, because of the learning curve. The first OO project or two will go more slowly than they should because you don’t know what you’re doing yet. Design is as hard to learn as programming. If you leap from training into an OO pilot project, you won’t prove your point — that the projects take less time and are less buggy — because the first project or two won’t be either.
I recommend two approaches. (I’ve done both at one point or another.) The less efficient way is to hire an expert designer to mentor a group through the process. The main difficulty with this approach is buy-in. It’s hard to convince many programmers that the design process is worthwhile until they see how much easier it is to write the code.
The better approach, in my mind, is to hire a good architect to do the design for you. (Several people, including myself, do this on a consulting basis.) Then have the architect come in, explain UML and how to implement from a design to the team, and then have the team develop the app under the architect’s supervision. This way, the first experience that the programmers have with OO is a good one: they see how easy it is to code when they have a design in front of them. Now they’re motivated to learn how to do the design work itself, and it’s at this point that you start the design training. I have worked in just this way (as the architect/mentor), so I know that it works.
The real issue, though, is that if you don’t adopt an OO-design process, you’re using Java on two cylinders. To get all eight cylinders, you need the design first.
Allen Holub
Senior Editor