Geeks With Blogs
Ulterior Motive Lounge UML Comics and more from Martin L. Shoemaker (The UML Guy),
Offering UML Instruction and Consulting for your projects and teams.

In our last Episode, Evil Tester used his newly gained UML skills plus his testing expertise to generate mountains of good news for The Reader. The Lounge is attracting attention from unexpected quarters, including today's new cast member... (Click the pictures for larger images.)

Episode 20a

Episode 20b

Why yes, I am reading Steve McConnell's Software Estimation right now. You should be, too. While he has earlier argued that requirements errors are the most common factor in project failures, here he shows that systemic underestimation is also a pretty significant factor (complicated, of course, by requirements problems). He shows you techniques that can improve your estimates to a 25% error range (with practice); but he also discusses what an estimate means, what it doesn't mean, how to revise it, and how to effectively communicate estimates and attendant risks to stakeholders.

And one of the fundamental techniques he describes is refining the problem down to a large number of smaller elements. Those smaller elements can then be counted or calculated or judged to produce a number of small estimates. And a fundamental truth of estimating is that many smaller estimates have less error than a few large estimates do.

And where can you find the smaller elements to estimate? Well, if you don't know my answer, you need to reread today's Episode... Long before I ever read McConnell's book, my estimating practice was good for about a 30% to 40% error range (when I followed it rigorously -- not following it is always a risk). And that practice is simple: don't estimate until I have at least a rich Use-Case-level model, and preferably a detailed Swimlane-level model; then build the estimate from the models I have.

Now when I do that, the estimate that results is usually one the customers don't like. They have a Target, and they want the Target to be the Estimate. But that's a contributing factor to the systemic problem that McConnell describes:

The industry data shows clearly that the software industry has an underestimation problem. Before we can make our estimates more accurate, we need to start making the estimates bigger.

Yeah, bigger estimates... That's gonna make stakeholders happy! Not! But they're already unhappy with inaccurate estimates. Much of McConnell's book is about better estimating techniques, but it's also about educating stakeholders on the use and value of accurate estimates. It also discusses ways to present and justify your estimates, and to use them as a basis for negotiating a feature set and a schedule that satisfies your target. By no means do I want to imply that this is easy; but I find that with a good model, I can lay out a case: "These are the things I'll have to build. This is how long I expect each one to take. And this is what those add up to. Is there any reason to believe that we can do any of these faster? Can we do any of these in a simpler, faster fashion? Are there any of these that you don't need for this release?"

And no, that conversation won't be pleasant; but it's necessary. Unpleasant up front is better than unpleasant in the end. Committing to do the impossible damages everyone: the team, the company, the customer, everyone. The customer will plan other parts of the business around a schedule that's never gonna happen. That ties up resources and funds and people that might be better used elsewhere.

Is there a risk in that conversation? Maybe; but if there is, you need to find a new job. If reality is taboo at your company, it's not a question of if you're going to fail, it's only a question of when. But before you abandon ship, try McConnell's suggestions. It may be very possible to work out a win, if you approach the discussion carefully.

OK, now that I'm done shilling for McConnell... (Not really. It's not shilling, it's enthusiasm.) Let's discuss some details of this Episode.

This Episode is loosely inspired by this film, but owes much more to this book. The Hitchhiker's Guide joke was irresistible.

I loved the idea that even Grim is afraid of the consequences of a HIPPA violation! If you're in health care software and you're not afraid of HIPPA, you're either very brave, or very foolish. They take privacy violations seriously, so your software had better do the same.

The Use Case Diagram in panel 6 introduces some new notation; or at least, new for what we've seen of Use Cases:

  • The triangle-headed generalization between Use Cases. You may recall from Episode 7 that the generalization arrow runs from the specific to the general. In Classes, the specific Class (a.k.a. the Child Class or the Subclass) added information or new behavior to the general Class (a.k.a. the Base Class or the Superclass). With Use Cases, a base Use Case defines a set of common rules and scenarios, and then a specific Use Case adds details or more scenarios. In this example, Reschedule is probably faster and easier than Schedule, since much of the information is already gathered. Maybe we can skip all the gathering steps and go straight to forecasting. On the other hand, Redo Missed is probably more complex, because we have to determine and set up an appropriate punishment.
  • The dependence (i.e., dashed arrow) from Visit Appt. to Redo Missed, tagged with the <<call>> stereotype. This indicates that somewhere during the course of Visit Appt., we may have to also perform Redo Missed. Let me emphasize that again: may. A given Use Case can contain multiple scenarios, and the included Use Case may be part of one scenario or all. The only way to be more specific is to drill in to the Activity Diagram inside the Use Case.

It's easy to go overboard with Use Case generalization and included Use Cases. Resist that urge! That can overcomplicate your Use Case Diagrams to the point where no one can read them and they lose their value. In particular, if your Use Case Diagram starts to look like a flowchart, you should be drawing an Activity Diagram. Use generalization and includes when they clarify and answer questions, not just because you can.

Model-View-Controller and data access layers are just a start to good architectural patterns. The Gang of Four and Martin Fowler have a lot more to say on this subject.

Please don't take the estimates in this Episode too literally. I did my best to make them plausible; but real estimates deserve more thought than I put into these. They're not a project plan; they're just a demonstration of the principle that:

Early estimates tend to expand with detail.

And yet they don’t expand indefinitely! It’s the early estimates that are most sensitive to detail. Notice how from panel to panel 9, we jumped from 5-13 weeks up to 15-31 weeks, or around a factor of 2.5-3. Yet from panel 9 to panel 11, we jumped only to 14-36 weeks. That’s a factor of around 1.2, or maybe even a decrease. This reflects the Cone of Uncertainty described by McConnell. As the development cycle proceeds through phases of maturity, the uncertainty goes down, and the estimates go down with it. I usually find that waiting beyond Swimlanes to do my estimates doesn’t add much accuracy, especially considering that it takes a lot longer. McConnell argues that the optimum time to make a “Commitment” estimate is after the user interface is sketched out and approved. He’s probably right, because the UI is the most tangible information the customer can see to provide feedback. But that takes a lot more time, and customers are impatient. I can take requirements all the way from idea to Swimlanes in relatively short order, so that’s where I prefer to estimate.

Note also that the summing technique I used here (sum the lows for the total low, sum the highs for the total high) is naive. I kept things simple to stay within the bounds of a comic strip. McConnell has much more sophisticated techniques to suggest, yet techniques that aren't that much harder to apply.

Oh, and did I mention that you should read Steve McConnell's Software Estimation? You should!

Posted on Saturday, November 15, 2008 5:08 PM Ulterior Motive Lounge | Back to top

Comments on this post: Ulterior Motive Lounge Episode 20: Final Meeting

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Martin L. Shoemaker | Powered by: