|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 5
There are many other aspects of the conversation. The people who test the software must understand what it is they are testing. Managers must communicate with developers, developers with managers, developers with other developers, managers with other managers, and so on. Throughout the lifetime of the project, small and large corrections in direction must be communicated. Priorities shift. Requirements change. Unforeseen problems are uncovered along the way. All these things must be effectively communicated as the process continues.
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.
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.