Sponsored Link •
Bill Venners: One of the early slogans about the object-oriented approach stated that it promoted reuse. But I think people found in practice that they didn't reuse much. Everybody needed something slightly different from what already existed, so they wrote that new thing from scratch. Perhaps things weren't designed for reuse, but, nevertheless, people still managed to build software. To what extent do you think reuse is important?
Josh Bloch: Reuse is extremely important but difficult to achieve. You don't get it for free, but it is achievable. The projects I do here at Sun -- the Java Collections Framework,
java.math, and so on -- are reusable components. I think they have been quite successful at being used by a number of vastly different clients.
In my last job, where I built systems, I found that 75 percent of the code I wrote for any given system was reusable in other systems. To achieve that reuse level, I had to consciously design for it. I had to spend a large fraction of my time decomposing things into clean, freestanding abstractions, debugging them independently, writing unit tests, that sort of thing.
Many developers don't do those steps. You touched on it when you asked how API design contrasts with extreme programming, and what do you do if you are a manager building something. One extreme programming tenet advocates you write the simplest thing that can solve your problem. That's a fine tenet, but it's easy to misconstrue.
The extreme programming proponents don't advocate writing something that will barely work as fast as you can. They don't advise you to forgo any design. They do advocate leaving out the bells, whistles, and features you don't need and add them later, if a real need is demonstrated. And that's incredibly important, because you can always add a feature, but you can never take it out. Once a feature is there, you can't say, sorry, we screwed up, we want to take it out because other code now depends on it. People will scream. So, when in doubt, leave it out.
Extreme programming also stresses refactoring. During the refactoring process, you spend much of your time cleaning up the components and APIs, ripping things into better modules. It is critical to do this, and to stay light on your feet -- don't freeze the APIs too early. But you'll have less work to do if you design the intermodular boundaries carefully to begin with.
Bill Venners: Why?
Josh Bloch: Because massive refactorings prove difficult. If you built something as a monolithic system and then find you had repeated code all over the place, and you want to refactor it properly, you'll have a massive job. In contrast, if you wrote it as components, but you got some of the component boundaries a little wrong, you can tweak them easily.
I think the disconnect between extreme programming and the API-based design process I espouse is not as great as it appears. When you talk to someone like Kent Beck [author of Extreme Programming Explained], I think you'll find that he does much of the same stuff I do.
To get back to your first question, if you are a manager, you should certainly give your team the latitude to create a good design before they jump in and start coding. At the same time, you shouldn't let them design every bell and whistle in the world; you should ensure they design the minimal system that will do the job.
Venners: So it sounds the extreme programming folks are trying to say, "Do the simplest feature set that could possibly work." But not, "Do the quickest slop you can throw down that could work possibly."
Josh Bloch: Precisely. In fact, people who try to "do the quickest slop you can throw down" often take longer to produce a working system than people who carefully design the components. But certainly, API design helps if you consider cost over time. If you throw down some slop, and, God forbid, the slop becomes immortalized as a public API that must be lived with for years, you really are toast. Such APIs become a tremendous support burden over time, and lead to great customer dissatisfaction.