Stay Focused on Executable Software

This third essential RUP principle has several facets. First, you should, to the extent possible, measure progress by measuring your executable software. It is great to know that 10 out of 20 use cases have been described, but that does not necessarily mean that 50 percent of the requirements are completed. What if you later find that half of those use cases require major rewrites because you did not properly understand the user requirements? That could mean that you were only 25 percent complete, right? So what you can really say when you have completed half of the use cases is that you are probably not more than 50 percent done with the requirements.

The best way of measuring progress is by measuring what software is up and running. This allows you to do testing and, based on testing and defect rates, assess the true progress that has been made. When the typical developer states, "I am 90 percent done," you should ask, "Great, but can you please demo what is up and running?" This will give you a solid idea of what has actually been accomplished. As an architect, team leader, or manager, you should always strive to have working software demonstrated and to look at test coverage and test results, rather than be fooled by the often false reality of completed documents. This does not mean that you should disregard the information in completed documents, but when considered in isolation, they provide a poor measure of true progress.

Second, a clear focus on executable software also promotes right thinking among your team; you run less risk of overanalyzing and theorizing, and instead get down to work to prove whether solution A or B is better. Forcing closure by producing executable software is often the fastest way of mitigating risk.

A third attribute of this focus on executable software is that artifacts other than the actual software are supporting artifacts. They are there to allow you to produce better software. By staying focused on executable software, you are better prepared to assess whether producing other artifacts ”such as requirement management plans, configuration management (CM) plans, use cases, test plans, and so on ”will really lead to software that works better or is easier to maintain. In many cases the answer is yes, but not always. You need to weigh the cost of producing and maintaining an artifact against the benefit of producing it. The benefit of producing many artifacts typically increases as your project grows larger, as you have more complicated stakeholder relations, as your team becomes distributed, as the cost of quality issues increases , and as the software is more critical to the business. All these factors drive toward producing more artifacts and treating them more formally . But for every project, you should strive to minimize the number of artifacts produced to reduce overhead.

A good guideline is that if you are in doubt as to whether to produce an artifact, don't produce it. But do not use this guideline as an excuse to skip essential activities such as setting a vision, documenting requirements, having a design, and planning the test effort. Each of these activities produces artifacts of obvious value. If the cost of producing an artifact is going to be higher than the return on investment (ROI), however, then you should skip it.

One of the most common mistakes RUP users make is to produce artifacts just because the RUP describes how to produce them. Remember, the RUP is a smorgasbord, and it is typically unwise to eat every dish at a table like the one in Figure 2.3.

Figure 2.3. Consider the RUP as a Smorgasbord. Consider the RUP as a smorgasbord of best practices. Rather than eat everything, eat your favorite dishes, the ones that make sense for your specific project.

Summary

Working software is the best indicator of true progress. When assessing progress, as much as possible, look at what code is up and running and which test cases have been properly executed. A strong focus on working software also enables you to minimize overhead by producing only those artifacts that add more value to your project than they cost to produce.