- 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
Birth of Murphy for Java
When I started on these laws, Java was new. The rate of failure on projects started to rise the moment larger projects started occurring. The problem was that even though Java was a better language, it was still susceptible to inexperienced developers and misguided management. My initial aim was to uncover the differences between Java development and C++, which preceded it in popularity. I did uncover several differences that would help a new developer, but I found more problems that were endemic to the design and development process: People, politics, education, and even emotion contributed to failure. The problem was recognizing when such issues were the cause of failures. I also started to realize that most software problems were caused by people's interpretations or a failure to analyze where problems come from and how to prevent them.
There are too many possible ways to write software. Huge variations are caused by personal judgments, personal choice, and even intuition. In other words, there is only technique and not repeatable sequences. Unfortunately, some developers look at software like art, when they should be looking at it as a complex problem that needs to be solved with the best answers rather than those that look the most artistically inspired. With risk management, we should be able to spot overly optimistic and artistic designs. We are also attempting to ferret out optimism and replace it with the reality that our best plans are still risky.
Managing Risks
The odds are good that your project will crash and burn, or exceed its budget, and/or your customers will hate your software and go elsewhere. Preventing these problems and having a successful project is much like making pigs fly. There are many barriers to success; even Java has its own set of problems.
The following are some basic tenets of Java development and accompanying questions, answers, and risk reducers. The answers have been broken into categories of Low Risk (which reduces risk) and High Risk (which signals big problems). The Risk Management points should be applied whenever possible—even if the general risk is low. As a developer, you can ask these questions to help you plan your project and avoid some trouble through specific actions. As a development manager, you can ask your developers these questions to evaluate the risk of a Java project. Here is how each law is presented:
The Law. A statement (hopefully witty) to help you understand the law, a question to be presented to the development team to discover risks, and a description of where the law applies.
Low Risk. Answers which, if proven true, indicate that the risks are low.
High Risk. Answers that indicate probable failure. Risk management should be a priority.
Risk Management. Possible actions to implement to reduce risk. Note that most of these strategies could be implemented even if the area is low risk, to further reduce the total risk.
Note that I haven't told you what the backup plans should be. The reason is that in most cases the correct action is to regroup, apply risk reduction, and then start over. Of course, the first step for a backup plan is to include the cost of such recovery. There are also other alternatives, such as refactoring or implementing different solutions.
The process to follow is to look at each of the following laws and compare them to your project. If there is a match, check for low risk and high risk factors. Depending on the risk, apply risk management techniques. If risk reduction is not easy or is politically impossible, plan a realistic backup plan—or even an exit plan if no recovery is possible.