- Engineering Complexity
- Birth of Murphy for Java
- People = Problems
- Education Through Pain Management
- The Twenty-Cent Solution
- Fraternal Clones
- "We Lost the Napkin"
- The Devil in Blue Jeans
- Jack and the Beanstalk
- The Slashdot Effect
- The Funhouse Microphone
- That "New Car" Smell
- If I Can See It, It Must Be Wrong
- The Ugly American
- Murphy's Law
- Use Egg Cartons
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Use Egg Cartons
The egg carton is an incredible invention. Egg cartons isolate very fragile and easily broken items into individual compartments that give each egg its own buffer. When you bump or drop an egg carton, odds are that you'll break only one egg out of a dozen. If you put all your eggs in one basket (all of the eggs touching each other), any impact will ripple through all of the eggs, causing much more damage. In software development, we want egg cartons.
The egg cartons of development are our guidelines and procedures. Just demanding a checklist of questions like those above will go a long way toward reducing a project's fragility. Instead of developers bumping into each other with random design principles and different technologies, levels of documentation, or even the amount and style of design, the procedures protect the integrity of each step and decision. Like an egg carton, less damage is possible because the procedures prevent a rippling of damaging decisions and their repercussions.
Why You Need Guidelines
Guidelines are a very important set of documents. They can give specific or generic explanations to common project tasks. Programmer guidelines are also useful to reduce errors from new developers or to break bad habits of older programmers.
Sun Microsystems has some of these documents, especially code formatting and naming conventions. Most of what Sun produces (and the hundreds of books published) follow a consistent formatting and naming convention. In fact, some Java technologies such as JavaBeans require specific naming conventions. Staying with the crowd in regard to naming and formatting means that most Java programmers will be able to follow any existing and future Java code that your company creates.
Here's a short list of documents you need to make specific to Java:
- Risk analysis and reduction
- Requirements planning
- Design requirements
- Prototyping guidelines
- Internationalization
- Platform testing
- Code walkthrough
- Java language usage guidelines
- Java formatting and comment requirements
- Capacity testing
- Capacity planning
- Source code control
- Change control
- Product rollout and delivery
Avoid Reusing Existing Guidelines
Java is not C++ and should not be treated as such. Your development process, from naming guidelines and code formatting to the breadth and content of requirements, all should be tailored specifically to Java. Reusing C++ standards can cripple Java development. For example, naming conventions that are used by some companies can prevent Java software from being usable in some development tools.