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.

Note: This was scheduled for tomorrow (hence the date drawn on the strip); but due to the U.S. Thanksgiving holiday, I'm releasing it a day early.

Continuing The Project That Time Forgot, a UML case study in comic strip form... (Click picture for a larger image.)

Ulterior Motive Lounge Episode 25: The UML Guy's Terms

 So in the previous Commentary, I wrote:

This Episode is all introduction. It doesn't include much UML content, and there's not much to add yet.

So naturally, this Episode has no UML content. But it was necessary to set the stage and to introduce common wisdom that somehow gets overlooked on project after project. I first saw this on the wall of a tire shop where my brother worked:

If you don't have time to do it right,
when will you have time to do it over?

So if they know that in the tire business, where the job is mostly well-defined, why don't we seem to know it in the software business with our nebulous requirements and goals? Oh, we say we know it; but when push comes to shove, we push and shove, when we should stop and think.

And push and shove is exactly the wrong thing to do! I know of no better metaphor for this way of thinking than Steve McConnell's pyramid builders (link is to a PDF). Please, please, please go read the whole thing! But here's the key description of the recurring problem:

The problem with the code-and-fix approach, as with the brute force approach to moving the stone block, is that quick movement off the starting line doesn’t necessarily translate into quick progress toward the finish line. The team that uses a more advanced approach is putting a framework in place that will allow the project to spin up to a high level of productivity and finish efficiently. It is putting rollers under the block, clearing the roadway, and preparing to focus the energy of the project team. The codeand-fix project gets the block moving early, but it doesn’t move the block far enough each day and the brute force approach isn’t sustainable. It typically leads to the creation of hundreds or thousands of defects early in the project. Several studies have found that project’s budget goes into fixing defects that were created earlier on the same project.

But that early "progress" is tempting. That early "progress" is seductive. That early "progress" is comforting, even if it's false. And most important, that early "progress" is visible. Stakeholders can see that things are happening. During up-front preparations, stakeholders can't see progress as easily, even if it's true progress, not just block-shoving.

So the situation shown in this Episode is common: stakeholders start out with enthusiasm for "doing the job right this time"; but then, when doing it right takes a long time and no code results, they get cold feet. They fall back onto "proven" techniques -- which mostly have proven to be difficult and costly; but because stakeholders get nervous, they grasp at tangible "progress" in lieu of visible progress.

Who do we blame for this? Do we blame the stakeholders? Nope. Oh, maybe a little: if they've been through this before, and it never worked before, then they should know better. A simple rule: if nothing ever changes, then nothing will ever change. But no, I don't think the stakeholders get the blame.

Do we blame Cowboy Consultant? Nope. Oh, he probably deserves some of the blame; but I'm reluctant to blame him, because at times I've been him. As Fred Brooks has noted, optimism is an occupational hazard of software development, and maybe even a necessary characteristic for surviving the field: the problems we face are so large and so complex and so interconnected that anyone who wasn't a foolish optimist would go find other work. It takes a certain mix of optimisim, hubris, and geekiness to throw yourself into the multidimensional problems that programmers tackle. So even though an experienced developer should know better, we all have a tendency to say, "Oh, that'll be fun! I can do that!". And then we leap in without thinking, before we even know what we're doing. But no, I don't think Cowboy Consultant gets the blame (but maybe a little of it).

So if we can't blame Owner, and we can't blame Cowboy Consultant, who do we blame? I can tell you who I blame in this case.

I blame The UML Guy. He really blew it.

Much of the disaster that looms in future Episodes could have been avoided had The UML Guy simply done one thing right the first time: make his work more visible and comprehensible to Owner, so Owner would want him to continue. When he worked for Owner before, he knew a lot of the power of modeling. He saw a lot of modeling benefits in his final code. But he was too isolated, and hadn't yet figured out that his processes must be open and visible and measurable and testable to the stakeholders. In other words, he hadn't yet figured out his primary message...

It's all about communication.

And yes, this is fiction (I've yet to be invited to consult on a project on a tropical island, darn it!); but in spirit, it's true. Even though I got a lot of use out of UML early on, I only saw the true power when I changed my focus from modeling to communicating through models. Then, and only then, did I start to become The UML Guy: a UML fanatic who today can barely carry on a development conversation without drawing some sort of diagram of what's in my brain. Heck, I find myself drawing diagrams for anything and everything, not just development. Remember: UML is not about software modeling; it's about system modeling, where system equals stucture plus behavior plus purpose. So I can use UML diagrams to communicate about many things in my business life and even in my personal life. It has become a language that I speak, not a tool that I use. And that brings a very different attitude. I don't think about UML, I think in UML.

Now all this discussion about modeling up front may sound like a direct attack on Agile Development. I'm sorry if that's how it sounds, but it's not. It's an attack on Agile Gone Awry. It's an attack on CAFÉ. I think Alan Cooper makes a strong case that requirements gathering and interaction design is a valuable precursor to Agile processes. Steve McConnell also makes a case that iterative or Agile work simply spreads this up front work across the iterations, and probably even increases the amount of up-front thinking (while also focusing the thinking, if you're doing it right.) Scott Ambler has written an entire book on the value and role of modeling in an Agile environment. And Martin Fowler, one of the original signatories to the Agile Manifesto, wrote perhaps the seminal book on UML.

I'm a big fan of Agile Development; but I think the idea that modeling and requirements analysis aren't Agile is just off base. In fact, I would contend that Agile UML is exactly what I've been promoting in the Lounge and elsewhere: UML as a language you speak, not a tool you buy and not a process you follow. In fact, some Agile practitioners who tell me they hate UML are really conflating it with the Unified Process and hating that. It's UP they're rejecting; but because they conflate the two, they entirely miss what UML is about. (And they're also misunderstanding the Unified Process, which in fact can be a very Agile process. But that's a discussion for another day.)

And I'm not a fan of Agile Gone Awry: Agile Development used as cover for cowboy coding. Sadly, I find that many shops that claim to be Agile are really just doing CAFÉ. Some developers will grab any excuse to avoid doing any process. They'd rather be coding. As I've said before, you have to honestly understand your process before you can judge or change your process.

So this Episode is The UML Guy's attempt to make up for past mistakes. He's more confident now. He knows that if he doesn't trust his team and his process, Owner never will either; and he knows the process has to be open and visible to Owner and everyone else, so they'll understand why it matters. Will he succeed? Owner starts out pretty skeptical, after all. We'll find out...

Some other notes on this Episode...

  • The computer in panel 2 is a Tablet PC. It's all The UML Guy uses these days. (And if you enjoy Ulterior Motive Lounge, thank Microsoft for creating Tablet PCs. I couldn't draw this strip without mine. Someday maybe I'll write a post on how I create a Lounge Episode. I also may someday do a post on the "art" of stickfiguration.)
  • The drinks in panel 2 are beer (on the right) and cranberry juice (on the left). The UML Guy doesn't know how you people can drink beer. The stuff smells vile. But he has friends who expect it in the Lounge.
  • Dog in panel 2 is a Welsh Terrier. You probably can't tell that from my stick figure art, but she is. She's friendly and loyal and cheerful. She also has a nose for critters, which may get her into trouble at some point.
  • The spiral staircase in panel 7 started with a simple problem. Well, two simple problems, really. First, the panel seemed kinda empty without it. (That's the same reason I added Dog to panel 2. Sometimes little things take on a big life of their own.) And second, in my map of the Lounge, I forgot to include space for The UML Guy's office. That led me to the idea of a basement office; and from there, a spiral staircase seemed natural. It's a good way to fit the stairs in a small space. But once I had the first version drawn (which was much simpler than this version), I thought, "Ya know, that stair edge and that hand rail with those support posts look a lot like a double-helix..." So expect to see those stairs again, or something like them, in a later Episode.
  • Editor Bill was puzzled by Geek Girl's nickname, "Terminator Barbie". Geek Girl will explain when she feels like it, and not until. (I explained the nickname to Jennifer Marsman, a real-life Geek Girl, and she approves. So I'm gonna keep the nickname.)

Next up: On the helicopter... In the mean time, remember: don't just do something, stand there!


Posted on Wednesday, November 26, 2008 7:04 PM Ulterior Motive Lounge , UML , Development Processes | Back to top

Comments on this post: Ulterior Motive Lounge Episode 25: The UML Guy's Terms

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

Copyright © Martin L. Shoemaker | Powered by: