Sponsored Link •
Where 'Flexible Java' fits in
So what part of this vast conversation did I hope to address in my writing? Put simply, I wanted to focus on the code.
How rare it is that maintaining someone else's code is akin to entering a beautifully designed building, which you admire as you walk around and plan how to add a wing or do some redecorating. More often, maintaining someone else's code is like being thrown headlong into a big pile of slimy, smelly garbage. You have to find some way to rearrange the garbage to fix a bug or make an enhancement. You regularly make appalling discoveries that grate against your design sensibilities. Now I don't like swimming around in garbage, and (I would hope) you don't either. Thus, my ambitious goal for my writing was to try and help reduce the amount of "garbage code" in the world -- to write a book that could help programmers produce better designs and code.
But what does 'good' mean?
The trouble is, what makes one design or piece of code "better" than another? What makes a design good? What makes code good? To address these fundamental questions, I'd first like to quote a few paragraphs from my first Design Techniques article, in a section called "Software development monkeys on your back":
In the real world, as you work to design and implement software, you have several concerns to keep in mind -- several "monkeys on your back." Each monkey competes with the others for your attention, trying to convince you to take its particular concern to heart as you work. One large, heavy monkey hangs on your back with its arms around your neck and repeatedly yells, "You must meet the schedule!" Another monkey, this one perched on top of your head (as there is no more room on your back), beats its chest and cries, "You must accurately implement the specification!" Still another monkey jumps up and down on top of your monitor yelling, "Robustness, robustness, robustness!" Another keeps trying to scramble up your leg crying, "Don't forget about performance!" And every now and then, a small monkey peeks timidly at you from beneath the keyboard. When this happens, the other monkeys become silent. The little monkey slowly emerges from under the keyboard, stands up, looks you in the eye, and says, "You must make the code flexible -- easy to read and easy to change." With this, all the other monkeys scream and jump onto the little monkey, forcing it back under the keyboard. With the little monkey out of sight, the other monkeys return to their customary positions and resume their customary activities.
As you sit there in your cubicle and work on your software, which monkey should you listen to? Alas, in most cases you must listen to all of them. To do a "good job," you will need to find a way to keep all these monkeys happy -- to strike a proper balance between these often conflicting concerns.
Basically, my opinion is that good designs and code strike a balance between flexibility, performance, and other concerns, but lean heavily toward flexibility. I believe that flexibility should be sacrificed in the name of performance only in rare, appropriate cases. Therefore, the guidelines and idioms I presented in the Design Techniques column were aimed primarily at helping achieve flexibility in Java code and designs. The upcoming book, Flexible Java, will have the same focus.
Why do I feel that flexibility is generally the most important quality you can give to your designs and code? The reason is that, as one of my managers used to put it, "software is a living product." Code isn't static. It is constantly being tweaked, enhanced, fixed, and so on, by a team of programmers, a team that is usually in constant flux itself.
The code is like a magical text that is constantly expanding and contracting, changing shape on the behest of a group of elite high priests and priestesses who know how to care for the thing. Flexibility is important precisely because the code must constantly be changed, day to day, month to month, year to year. The more flexible the code is -- that is, the easier it is to understand and change -- the more smoothly and efficiently this fundamental activity of software development can take place.
So, flexibility is the prime focus of the guidelines and idioms I presented in the Design Techniques column. I hope the articles in this column have helped the software development conversation in many corners of the world, and that they continue to do so in the future. As always, the previous issues of JavaWorld will remain online, so you should always be able to get to Design Techniques material.