Personal

Calculating the ROI for Requirements Analysis

Martin L. Shoemaker — Tue, 05 May 2009 00:53:37 GMT

My buddy Josh Holmes has written a very excellent post on the Return on Investment (ROI) for software. I recommend it to anyone who sees software as a business, not just a job or a hobby.

Last week, the always-worth-reading Patrick Greene made a comment that made me start thinking specifically about the ROI for Requirements Analysis. Most teams and most managers know they have a requirements problem; but too many of them say, “But we’re too busy to fix it, so we’ll just start coding.” Or “We’d like to fix it, but we can’t, so we’ll just start coding.” Or “Yeah, but our customers won’t answer our questions, so we’ll just start coding.” Or “Our executives want progress, they want us to just start coding.”

And that leads me to name a common, pernicious antipattern, JSC: Just Start Coding. This is not Agile Development, but it masquerades as Agile. It really means, “We’re gonna be late no matter what we do, and our executives are wondering why we’re not coding already. So we’re gonna Just Start Coding, and call it Agile.”

Which is exactly wrong. Good Agile, real Agile, is very requirements-centric. It’s about surfacing requirements and particularly requirements miscommunications quickly and frequently, so that we stay as close to the right path as possible, and waste as little time as possible on wrong paths. Agile makes short, quick moves, and short, quick corrections.

JSC, on the other hand, just makes quick movement, with no mechanism in place for planning and correction. “We’re on the wrong path? Who cares? At least we’re coding!”

And yes, let’s admit the dark side: we developers often contribute to this mess. Coding is comfortable. Requirements analysis (for many of us) is uncomfortable. It’s really easy to ignore nagging doubts and bury your concerns in lots of fun coding challenges. “Well, it doesn’t make sense to me; but this is what they asked for, so this is what I’ll build.” We abdicate responsibility for the wrong requirements.

But I want to follow in Josh’s footsteps, discussing software as a business, not just a job. And for a business, JSC has a cost. A huge cost. And Requirements Analysis can eliminate much or all of that cost. Maybe a little ROI calculation can help us to win executive support to do the job right.

Some Fundamental Assumptions

The ROI calculations that I’ll make are based on three fundamental assumptions: two from industry research, and one from faith.

Barry Boehm’s COCOMO II research tells us that poor requirements analysis can add 40% to as much as 100% to your schedule.
Many different sources (summarized by Steve McConnell) tell us that the average project is underestimated by roughly 100%.
Those were the research; here’s the faith. I contend that with a relatively minor investment of time compared to the overall schedule, your team can drastically improve your requirements, reducing that 40-100% schedule slip to nearly zero.

You can’t fix the tendency to underestimate (though you can make a good start by reading Steve McConnell); but I believe that most of what you need to fix requirements failures is simply paying attention to requirements early and refusing to ignore the obvious failures. I’ve worked on too many teams where everyone knew the requirements were fatally flawed, yet no one did anything about them. Everyone saw those flaws as “just the way things are around here”. They erected a giant SEP field around the requirements flaws, and they Just Started Coding.

I don’t think it has to be that way. I think that we as developers have the responsibility and the power to fix most of our requirements problems, if only we can persuade our managers to let us – and persuade ourselves to try. I’ve written a whole book (coming soon, I hope) on how we can perform better as Analyst-Developers; but to get management to back us, we have to show them a business reason. The assumptions above are part of that reason.

A Tale of Four Projects

To perform my ROI calculations, I’m going to envision four projects. Well, no, not really. Rather, I’m going to envision four different scenarios for the same project:

Just Start Coding (Typical). In this scenario, the team starts coding from the earliest possible moment. Management has a target date (they’ll call it an Estimate, but McConnell will call that a delusion). The more likely date is twice as far down the road, per Assumption 2 above; and then because the team fails to do adequate requirements analysis, the final schedule is 1.4 times that doubled schedule, for a total of 2.8 times the expected duration.
Just Start Coding (Out-of-Control). This scenario is similar to Just Start Coding (Typical); but the requirements analysis is even worse than usual, adding another 100% to the project. And these are factors, not sums; the final duration is 4 times the expected duration.
Analyzed (Time Bound). In this scenario, we assume enough Requirements Analysis at the start to recognize that the project cannot possibly meet the target date; and management tells us that the date is sacrosanct. We must meet that date, even if we have to cut features to do so. It’s always smarter and less error-prone to cut those features at the start than at the end, so we do so. Then we continue a small fraction of Requirements Analysis throughout the duration of the project, likely trimming more features as we go. We hit the target date with a lean but critical subset of the desired features, and a high-quality implementation of those features. We’ll add the other features next time.
Analyzed (Feature Bound). In this scenario, we assume enough Requirements Analysis at the start to recognize that the project cannot possibly meet the target date; and management tells us that the features are sacrosanct. We must supply those features, even if we have to slip the date to do so. Our final schedule will be 100% longer than the target; but when we finish, we’ll have the complete set of desired features, and a high-quality implementation of those features.

Obviously, some managers or customers will want Time Bound and Feature Bound. It can’t be done. Break the news to them gently.

Oh, all right, I know: some managers will demand Time Bound and Feature Bound. Let’s call this Scenario 5. It’s the Scenario where you do the analysis right up front, realize there’s no way to succeed, realize that management demands you violate the laws of space and time, and get your resume out on CareerBuilder.com so that you can be working somewhere else when the mandatory overtime and the punitive firings and the lawsuits begin. But since there’s no ROI for Scenario 5, we’ll ignore that scenario as we go forward.

More Assumptions

Next we need a few more assumptions (based on my personal experience, believe them as you will) and some parameters. First, the assumptions:

Up-front analysis requires only about 10% of the likely schedule. If your target is 6 months and so your likely schedule is 16.8 months (6 * 2 for estimation error * 1.4 for analysis error), then your up-front analysis time is about 1.68 months.
Because the analysis is work you would have to do to succeed anyway, just pushed to the front of the discussion, it involves the whole team, and yet doesn’t add to the final schedule.
Analysis is a skill most teams don’t have in abundance. You need a few skilled lead analysts to work with the team, roughly 1 lead analyst per 5 team members.
Once the initial analysis is done, you need little bits of analysis throughout the rest of the project. That will involve the lead analysts for about 20% of the total remaining schedule.

If you don’t like those assumptions, you can treat them as parameters and vary them; but these values fit with my experience.

As for the parameters, you really only need two:

How much does an hour of a developer’s time cost you (total)?
How much does an hour of a lead analyst’s time cost you (total)?

And that’s all you need to know. The rest of the possible factors – duration of the project, team size, etc. – all divide out, because everything is calculated as ratios of time to time, dollars to dollars, and so on. ROI is a relative measure.

And to be honest, you really don’t need to know the absolute costs for developers and lead analysts, just the ratio. As long as the ratio remains constant, you can plug in any values you like.

The Results

So given those assumptions and parameters, what’s the ROI?

Are you sitting down?

My parameters have a lead analyst costing 50% more than a developer. I don’t usually find that to be the case, but I wanted to make analyst costs relatively high to skew the ROI down.

And even with that skew, I ended up with these calculations:

An Analyzed (Feature Bound) project has an ROI of 652% when compared to a typical JSC project, and 2,081% when compared to an Out-of-Control JSC project.
An Analyzed (Time Bound) project has an ROI of 1,943% when compared to a typical JSC project, and 3,371% when compared to an Out-of-Control JSC project.

Those are astonishing ROI figures. Unheard of ROI figures.

And of course, those are ideals. Your Requirements Analysis won’t be 100% effective at cutting out lost time. Let’s assume you only cut out half the lost time that’s due to requirements failure. Then you get numbers like these:

An Analyzed (Feature Bound) project has an ROI of 24% when compared to a typical JSC project, and 776% when compared to an Out-of-Control JSC project.
An Analyzed (Time Bound) project has an ROI of 364% when compared to a typical JSC project, and 1,116% when compared to an Out-of-Control JSC project.

Still nothing to sneeze at. And I think you can do a lot better than just half. I know I can.

And although I've only calculated ROI based on labor savings, labor costs are not the only costs associated with requirements failures. Requirements failures increase costs across the board. Besides a longer schedule, you get more overtime, higher shipping costs, higher travel costs, missed commitments, lost opportunity costs, interest payments, performance penalties… even costly litigation.

And there's also a cost in quality. Reworked code has more bugs than original code. The rework is done under tighter deadlines, there’s more pressure, and there’s more overtime. Developers cut corners in response. This results in more bugs; and those bugs lead to more delays and even more schedule pressure. There's a nasty feedback effect here, and it can kill a project. Requirements Analysis can cut that feedback loop.

Conclusion

Again, this is not BDUF. I just spent a week at a client’s site, and spec’ed out their major requirements in that week in more useful detail than they had developed in months. Better Requirements Analysis does not mean bigger; it means more thorough. It means recognizing when you have questions, and making sure you answer them. It means identifying priorities and making choices.

And it means some resistance. It’s not by accident that we have a systemic problem with requirements in our industry. But it’s in our power to change that.

My spreadsheet for this ROI calculation is available if you want it. Leave a comment. If you disagree with any of my assumptions, leave a comment about that, too. I want to make the most clear, justifiable case possible to my stakeholders (and to yours!) to convince them that Defining the problem in a comprehensible, verifiable form is necessary to solving the problem.

Weird Word 2007/PDF Bugs

Martin L. Shoemaker — Wed, 22 Apr 2009 18:05:56 GMT

Here’s a screenshot of my document in Word 2007:

That’s exactly what I wanted: three columns in different shades. Hurray for Word 2007!

Then I saved as PDF. Here’s a screenshot from Acrobat:

I don’t know why the colors “leaked” like that, but it’s bad.

And while I could imagine this being Acrobat, not word, this is clearly Word’s fault. I added a line to Column C, but made no other changes. Here’s the screenshot from Word:

More of the same strange color leaking. Not acceptable, not in my marketing literature! I hope I can track down a fix or a workaround.

Note: Any suggestions to switch to Google Docs or another alternative will be politely ignored. I love Office. I’m a power user and more. I can’t live without its mountains of powerful features that work exactly the way I expect. But that doesn’t stop me from whining when I want more, especially when I want a bug fixed. For once, I’m the end user, not the developer; and as a developer, I know this unshakable truth: end users whine, no matter what you give them. It’s my turn to whine.

UML... It's not Rocket Science

Martin L. Shoemaker — Fri, 10 Apr 2009 20:08:36 GMT

If you follow me on Twitter, you may have seen a strange tweet yesterday:

Looking for a word... "Employee" is to "Roster" as "Vehicle" is to _____? "Fleet" doesn't seem quite right.

With a lot of helpful suggestions, especially from @patrickgreene, we settled on “Fleet Manifest”. It’s ideal for what I needed.

But in case you’re wondering why I needed that term, here’s a slide from the UML QuickStart class from 213 Software Studios (click pictures for larger images):

And here’s another:

"Think one through..." is what we'll do after these slides. I'll show you diagrams of the concepts first, so you know what we're trying to accomplish; and then together, we'll think through a live example. And then you and your team will do your own examples, and I'll help you get it right.

These are just a tiny sample of what you’ll get in a full day of intensive hands-on UML training. Email John T. Hopkins at jhopkins@213softwarestudios.com or call (248) 425-8549 for more information.

Jaded

Martin L. Shoemaker — Thu, 19 Mar 2009 22:54:42 GMT

Once upon a time, I had a really thorny development problem to solve. I needed to build a histogram of the colors in a true-color image. There was a theoretically easy way to do this. If I had had C# then, the code would’ve looked like this.

int[,,] histogram = new int[256, 256, 256];

for(int y = 0; y < bmp.Height; y++)

{

    for(int x = 0; x < bmp.Width; x++)

    {

        Color clr = bmp.GetPixel(x, y);

        histogram[clr.R, clr.G, clr.B]++;

    }

}

This was the brain-dead simple way to build the histogram. Only one problem: it required 16million 32-bit counts, or 64 megabytes.

64 M*E*G*A*B*Y*T*E*S OF RAM, MAN! ARE YOU MAD? THAT WOULD COST US $50,000!!!!! The whole SYSTEM is supposed to cost under $30,000!!!

Well, OK, for some of you, that just pinpointed the year, more or less. There was no way on Earth we could ship a system with 64 MB. Instead, I built a complex and ultimately failed algorithm to build a sparse histogram. I solved the general problem of sparse histograms – with a solution vaguely like what you’ll see below, but less elegant – but I couldn’t easily ascertain color proximity within the histogram. That was just too difficult. It took me months, and it never worked perfectly. Like Alan Cooper says, the bear danced, but never well.

Today, I am almost never without two memory sticks, a memory card, and a phone that collectively add up to about 3 GB. I sometimes forget I even have the card.

And so today, I could actually build the algorithm above (if I still needed it); and it would run in an insignificant amount of memory.

But why bother? I realized that Microsoft had given me simple tools for building a sparse histogram:

Dictionary<System.Drawing.Color, int> histogram = new Dictionary<System.Drawing.Color, int>();
for (int y = 0; y < bmp.Height; y++)
{
    for (int x = 0; x < bmp.Width; x++)
    {
        System.Drawing.Color clr = bmp.GetPixel(x, y);
        if (histogram.Keys.Contains<System.Drawing.Color>(clr))
        {
            histogram[clr]++;
        }
        else
        {
            histogram[clr] = 1;
        }
    }
}

There it is. It works. It’s maybe not efficient, but it’s simple. It still doesn’t solve my color proximity problem (hey, I’ve gotta keep some of my secrets to myself for a while); but it works, and it took me less time to write than I’ve spent on this blog post.

And when it was done, and I found that it didn’t address the problem I was really trying to solve (trying to figure out why my bitmaps aren’t transparent), I threw it away.

Code that once took me weeks, written more elegantly in minutes, and casually thrown away as trivial.

I am so jaded…

Usability 101: Don't Do This! (I'm Talking to YOU, Microsoft!)

Martin L. Shoemaker — Fri, 13 Mar 2009 23:54:45 GMT

From PowerPoint – 2007, no less!

On one page, we can set the size. X and Y are arranged horizontally, Y first.

On the next page, we can set the position. X and Y are arranged vertically, X first.

This has confused me practically every time I’ve had to edit the size of something in PowerPoint. I know it’s there. I do. But the behavior is so counterintuitive, I just can’t get my brain to think this way. It’s just wrong!

Personally, I would prefer size and position on the same page; but I can see the argument for separating them, since size has so many options.

But changing their layout and order is practically begging users to make mistakes.

Smooth move, PowerPoint team…

Some Recruiting and Placement Resources, in Case You Need Them

Martin L. Shoemaker — Wed, 11 Mar 2009 19:11:02 GMT

Based in part on PC Magazine’s Top 20 list. Offered in alphabetical order, with no comment on quality or usefulness. But I hope you find them useful. Feel free to comment with more.

Advanced Technology	AITC	AJM Professional Services	AMTEC Systems Corporation
Aquent	Austin Park	Azad	Balionis Group
BetaTech, Inc.	Beyond	Bill Young & Associates	Bren Norris Associates, Inc.
CareerBuilder	Careernet.com	CIBER	Computer Express, Inc.
CraigsList	Creative Group	Creative Hotlist	CyberCoders
Data Search Network, Inc.	Dice	Execu\|Search	Finders Inc.
Grand Rapids Gigs	Hound	Indeed	JobCentral
JobFox	JobServe	Jobster	Karl Associates
KForce	MEDC Business Directory	Michigan Job Network	Monster.com
onTargetJobs	Oodle	Otterbase	Paragon Recruiting
PCPI Inc.	Prime Source Management Inc.	SetFocus	SimplyHired
SoloGig	Spherion Corporation Stout Systems	Sunfield Consulting
Technisource	TEK Systems	The LaSalle Netowrk	The Normandin Group
Trovix	True Source Recruiting	TweetMyJobs	USAJobs
Vault Technology Jobs	Williamson Employment Services	Yahoo HotJobs

Stray quote for the day…

Martin L. Shoemaker — Wed, 11 Mar 2009 15:59:17 GMT

By and large the literature of a democracy will never exhibit the order, regularity, skill, and art characteristic of aristocratic literature; formal qualities will be neglected or actually despised. The style will often be strange, incorrect, overburdened, and loose, and almost always strong and bold. Writers will be more anxious to work quickly than to perfect details. Short works will be commoner than long books, wit than erudition, imagination than depth. There will be a rude and untutored vigor of thought with great variety and singular fecundity. Authors will strive to astonish more than to please, and to stir passions rather than to charm taste.

Alexis de Tocqueville (1805–1859), French social philosopher. Democracy in America, vol. 2, pt. 1, ch. 13 (1840).

Spider

Martin L. Shoemaker — Wed, 25 Feb 2009 18:21:53 GMT

A small benefit of being between gigs: I’m sitting here, coding and networking and working and planning, while watching From the Earth to the Moon Episode 5: Spider. If you’re any sort of an engineer, you need to watch this every year (or more) for inspiration. It’s the best, truest picture of engineering I’ve ever seen on screen. And for me, it’s a reminder: my job is not hard. That was hard, and they did it. I can do this.

I also recommend Thomas J. Kelly’s Moon Lander for the story behind Spider. It’s kinda dry, but it’s an amazing look at a period in engineering history when they were inventing and discovering the project management techniques we take for granted today. Oh, and they sent men to the Moon.

The U-Shaped Curve (A few more reasons why Coding Geekette is right)

Martin L. Shoemaker — Fri, 09 Jan 2009 19:18:29 GMT

Note: This is a Best Of post from my other blog. The topic came up on Twitter, so I'm rerunning it here.

Coding Geekette has a slightly dated but still timely post about The Making of a Good Developer. That post was inspired by Justin Etheredge's equally interesting post on why Being Smart Does Not a Good Developer make. Both address the idea that good developers are those who like to learn new things, not just smart people. And they lament or wonder that so many people in the software development industry aren't interested in learning new things. I admit, this attitude puzzles me. I love to learn. I remember as a kid watching M*A*S*H and seeing that Hawkeye and BJ were reading medical books and journals, even though they were already doctors. I asked my Mom, and she explained that doctors have to keep learning new stuff all the time. I thought that sounded incredibly cool; but eventually, I learned that most kids didn't like school, and thought the idea of learning all the time sucked. I didn't get it, and I still don't.

But lamenting isn't my style; and wondering about someone's motivations isn't productive (better just to ask them). But being a proactive kind of UML Guy, I prefer trying to persuade them, through the power of raw, naked greed.

And that brings us to the U-Shaped Curve, which will eventually lead to a great argument for why they should keep learning. Now this idea isn't original with me. I would swear I learned it from John Stout at an AACS presentation; but John denies ever mentioning it, so it must've been a panel he hosted. Someone on that panel deserves credit, but I can't recall who. Update: Josh Holmes tells me it was Bill Wagner.

The basic idea of the U-Shaped Curve is seen in this picture:

Figure 1: The U-Shaped Curve

The axes of the Curve are:

Newness (horizontal): Newer technologies toward the right, older technologies toward the left. And remember, today's Bleeding Edge will be common in a few years, and Paleontological in a couple of decades.
$ or Value (vertical): More $ toward the top

The idea is simple supply and demand: if you know a Bleeding Edge technology, you can charge through the ceiling, because nobody knows it. And if you know a Paleontology technology, you can charge through the ceiling, because everybody else who knows it is dead. But if you know only common technologies, you sit in the bottom of the U, with the bottom rising or occasionally sinking over time.

Now there's a complication for both Bleeding Edge and Paleo: you have to find someone who needs those skills. For bleeding edge, that's especially difficult, because few people know those skills even exist. For Paleo, it's a little easier, because those skills are known, proven technologies. Of course, they're technologies that have mostly been abandoned years ago, but they're still better known than the Bleeding Edge stuff.

A lot of people aren't interested in chasing the Bleeding Edge; and most people aren't learning Paleo tools just for fun (some do), so only time will make them Paleo experts. But of course, those are only two extremes on the curve. There are some pretty common waypoints as well (as described in Steve McConnell's Professional Software Development):

Figure 2: Waypoints along the U-Shaped Curve (inspired by Steve McConnell)

Early Adopters. These people jump on new technology as soon as it's publicly released. Between the Early Adopters and the Bleeding Edge are the Scouts: people who like to learn about the pre-release tools, but aren't going to jump in with both feet until the tools near release. (I'm a Scout by temperament. I don't have the time to keep up with Bleeding Edge, but I want to see what's coming.) Early Adopters can't charge as much as Bleeding Edge folks; but they're pretty valuable, and they have more opportunities.
Middle Adopters. These people jump on new technology later, usually when they finish their current projects and start on new projects. Of course, since projects frequently run over schedule, and since new tools sometimes -- sometimes! -- can make help you to meet a schedule, these people may be too cautious. (In fact, I would argue that they're usually too cautious; but that's a very long discussion, and I'm tired.) Middle adopters are near the bottom of the U, but probably still above it.
Late Adopters. These people think they're being safe by waiting until a technology is "proven". What they're really doing, more often than not, is being too cheap or too busy to learn anything new. These are the people Coding Geekette wonders about. They willingly give up a competitive edge to all the Early and Middle adopters who aren't so short-sighted. This is a false economy. And it makes it hard to attract and retain good people like Coding Geekette, who thrive on constant learning. Plus the U-bottom rates these companies pay won't catch the attention of anyone who can work higher up the U.
Forced Adopters. These people cling to old technology until it's no longer supported. Then, kicking and screaming, they upgrade. The people who work at these companies may cling to their old skills long enough to reach Paleo, or they may slide back to the U-bottom. If they're smart, they'll grab the opportunity to move to Leading Edge. It's often easier to just skip all the intermediate generations of technology and go straight to the new stuff; but that takes a willingness to change that's rare in Forced Adopters.

Now you might look at Figure 2 and think, "Eh, Middle Adoption's not that bad. The pay is decent, and you don't have to deal with all the Version 1 bugs. That's what I'll do." And that can work (though McConnell describes some real opportunity costs you can lose if the Early Adopters pick a really good technology that gives them an edge over you). But you have to pick your next sentence carefully. Is it...

"So I'll learn this stuff that's been out for a while, and then just keep using it until it's phased out."?

Or...

"So I'll learn this stuff that's been out for a while, and then next year I'll learn the stuff that's new this year, and then the following year I'll learn the stuff that's Bleeding Edge right now, and..."?

If you're Coding Geekette (I hope she doesn't mind me using her as an example over and over again, but I thought her post proved that she has the right attitude), you'll give the second answer, because you love to learn this stuff. (Although I suspect she's probably more of an Early Adopter, from her post). But if you're in this field for a job not a passion, you may be tempted to give the first answer.

Don't.

If you have kids to put through school, or you have a mortgage to pay, or you just want to buy a nice fishing boat and spend summers on the lake, give the second answer.

Because remember: the whole U-Shaped Curve isn't static: it keeps sliding to the right, so static skills keep sliding to the left. Your skills that are new today are common next year, and old the year after that. Unless your career plan is to Go Paleo (live through the curve bottom and ride out the trailing edge), sooner or later you'll find yourself in Forced Adoption. That's a hard spot to ever escape, and it's not a spot with high financial reward.

In fact, becoming a Late or Forced Adopter can lead to financial or career risk, because pay rates aren't static, either. Unless your company's fortunes turn really bad, most employees can count on some sort of pay increase over time, even if only a cost of living adjustment. So at the same time your static skills are sliding down the U, your pay is increasing:

Now at first glance, that looks attractive: "You mean I can beat the curve simply by holding my ground?" But that's a trap. At some point, your pay so far exceeds your worth on the curve that no one but your current employer would conceivably pay that much for your skills. In the mean time, if you're a typical person, your cost of living has increased due to many factors: inflation, growing family, kids in college, etc. So that means your only choice for work is your current employer. Is that bad? Not at all, for some people; but if you want options in your career, static skills are not the way to get them. And you also risk becoming too expensive for your employer: you can be replaced by someone with the same skills but a much lower price tag. (Note: This simplistic analysis ignores your accumulated knowledge of the company, its business, and its customers. The U-Shaped Curve is not the only measure of your value to the company, and it's short-sighted for employers to think it is.)

But suppose you love your current employer and wouldn't ever want to go elsewhere. In that case, you still should keep moving to keep your skills up to date (wherever you pick on the U). After all, if you like the job, don't you have loyalty to them? Don't you want them to succeed? At a minimum, don't you want them to stay in business so you can keep enjoying the cushy job? Well, if your skills are static and your pay isn't, then your employer is effectively losing value. Don't you want to maintain or even grow their value in order to protect your job? Now one way to grow their value is through your expanding expertise in their business and customers; but another is to keep growing your skills.

So I think that if you're in software development, you're in the learning business or the falling-behind business. This may not appeal to you, and I'm sorry, but that's the way it is. Some people don't invest themselves in their work: they may work competently and professionally, but work is simply what they do to support their lives and lifestyles. But some people like to find a task, master that task, and keep improving until they're the best they can be at that task. They take pride and pleasure in knowing their job and doing it well. And finally, other people like to keep finding and tackling new challenges. They take pride and pleasure in new conquests and new things they know (and may quickly get bored with the old challenges). If you're not in the last group -- or you can't at least act like you are -- then software development may be the wrong profession for you.

So my advice to those who want to excel as developers: Run! Run like the wind!

Ulterior Motive Lounge Episode 29: Touring the Pavilion

Martin L. Shoemaker — Tue, 16 Dec 2008 02:03:15 GMT

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

“We grow dinosaurs!” Big whoop, huh? Like anyone reading the strip hadn’t figured that out before I started Scene 1… It’s hard to surprise the characters in a story when the audience can tell from the promos what the surprise is.

But since The UML Guy has been part of the project before, none of this was a surprise to him. So while the others were taking in the new sights, he was drawing more UML diagrams. His results follow.

We learned a few more specific kinds of scientists on the project:

We added one more category of Employee Actors, Information Staff:

If you’ve ever eaten at a restaurant – certainly if you’ve ever worked at one – you’ll realize we need more detail in our set of Concession Actors, starting with a Restaurant Manager:

And then more specific Restaurant Staff:

We also learned of more systems we’ll need to support the functions described in the Episode:

We added an Information Console, a Laboratory Server, Laboratory Computers, Laboratory Devices, a Commerce Server, and Cash Registers. Note that the Commerce Server has to communicate with the Warehouse Server to schedule deliveries to the rooms and to the mainland.

These new systems complicated the physical Deployment Diagram almost to the breaking point. It’s complex enough that The UML Guy plans to group it, simplify it, and turn it into multiple diagrams when he gets time. But for now, here’s one more look at the single diagram:

We added some new Use Cases for Driver:

And for Guest:

One of those Use Cases, Make Purchase, is complex enough to deserve a dedicated diagram:

We can see from the Episode that there are multiple Classes of souvenirs:

And finally, we have new Use Cases for the Geneticist and the Embryologist. Normally, The UML Guy prefers a single diagram per Actor, focused on the Use Cases for that Actor; but in this case, the Use Cases are closely related and work with related Domain Objects. So he combined the diagrams for now, but may split them later:

That’s it for new UML content for this Episode. Oh, The UML Guy could imagine more, such as Use Cases for the Restaurant Staff and the Souvenir Staff; but Owner just didn’t give enough detail to work with. Those will come out over time.

Other comments on this Episode:

The sign post in panel 2 probably ought to include Seoul, Ottumwa, Mill Valley, Boston, and Crabapple Cove; but that would’ve made it unreadable.
It’s not the Dino Dog that’s bothering The Reader in panel 6, it’s the curry. The fastest way to drive him away is to serve him curry. But boy, curried chicken sausage sounds good to me right now!
Since you insisted (I know you’re thinking it, here’s the recipe for Yabanapple Soup:

Yabanapple Soup (Serves 4)

3 large ripe bananas

1 large sweet potato (sometimes called a yam in America, but not the same as yams elsewhere – it’s a whole different genus and species)

1 large can of chunk pineapple, drained

2 large cans of whole coconut milk (skim if you prefer)

3 tablespoons of honey

1 dash cinnamon

1 dash nutmeg

Clean and peel the sweet potato.
Boil a pan of water. When boiling, add the sweet potato, and boil until slightly soft. Remove from heat and drain.
Peel and slice the banana into quarter-inch slices.
Slice the sweet potato into quarter-inch slices, and then into chunks.
In a sauce pan, mix coconut milk, sweet potato chunks, banana slices, pineapple chunks, honey, cinnamon and nutmeg. Heat until simmering.
Serve hot; or chill and serve with a scoop of ice cream.

Boy, those are some cool-looking souvenirs in panel 7. Let’s take a closer look:

Wow! Too bad this is just a comic strip, not the real world. Wouldn’t it be great if there were a place where you could buy LoungeWare, especially just in time for Christmas?

Wayne H. Boring was a famous and popular Superman artist. I love his work, and I couldn’t resist borrowing his name for the pun in panel 8.

Next Episode: a tour of the Labs!