Code is not Enough

Ulterior Motive Lounge Episode 32: Talking with Pilot

Martin L. Shoemaker — Wed, 04 Mar 2009 22:06:48 GMT

Continuing The Project that Time Forgot, a UML case study. (Click images for larger versions.)

On the surface, this Episode may seem almost social. Demented and sad, but social. But if you could join Hacker Girl, reading Geek Girl’s Tablet PC over her shoulder, you might see a different picture:

And you would also see this diagram:

You saw a conversation. Geek Girl hopes that Pilot saw a conversation. But she saw an interview, and a chance to capture and model requirements. Let’s review the notation here and discuss the diagram contents.

The ellipses are the use cases that a driver performs (indicated by the arrows from Driver to the use cases).
Dependencies (dashed arrows) with the <<include>> stereotype indicate that one use case includes another within at least one of its scenarios. So in order to Get Destination, the system must Scan GPS IDs.
The triangle-headed arrows (generalizations) indicate that one use case is a special case of another use case. So Contact Ops via GPS, Get Time from CIS, and Get Weather from CIS each has a special case that uses Voice Command; and each of those special cases is defective.

You might ask: “Why is Maintain Car in this diagram? Aren’t they modeling what the computer systems will do? Does the computer have any role in car maintenance?” And that’s a legitimate question. If the team were modeling the entire business, Maintain Car would certainly be a use case in the model; but why did Geek Girl include it in the system requirements model?

The answer is two-fold:

Pilot mentioned reflashing the engines, which is a computer-driven operation. As indicated in Geek Girl’s notes, it’s not clear at this time whether the Park’s computers are involved in reflashes or not. The reflashes may be done by dedicated tools that have no connection with Park systems; but it may be that the Park maintains records about the reflashes. Just in case, Geek Girl wanted to capture this.
And building on 1: it’s always best to capture whatever a user says, even if you’re not sure it’s relevant. You can always remove it later. The analyst’s first job is to listen and capture. Analysis and filtering comes later. Don’t filter while you’re listening, filter later!

But then you might ask: “Why did Geek Girl stop there? Why didn’t she include use cases like Fly Helicopter and Rebuild Diesel Ferry Engine?” The answer is that she ignored what I just said, and she filtered now. “Filter later” is a good guideline, but you do have to apply some measure of judgment. Certainly “Watch Your Language” doesn’t involve the computer system, so she knew she could ignore that. Fly Helicopter and Rebuild Diesel Ferry Engine are less clear; but there’s certainly a good reason for leaving them off this diagram: it’s a diagram of Driver use cases, and those aren’t Driver functions. Pilot does them, true; but when he does, he’s not acting in the Driver role. Because remember: actors are roles people or things can play, not the people themselves; and one person or thing may play multiple roles.

If you’re still uncomfortable with the distinction between Maintain Car and Rebuild Diesel Ferry Engine, good! Welcome to the world of requirements analysis! There are no hard and fast rules. There are no clear lines, only guidelines. You have to apply judgment; but as a general rule, err on the side of capturing more information, not less. Geek Girl captured a lot of notes on her Tablet PC, while converting the most clearly relevant ones into a diagram. After the interview, Geek Girl will find time to clean up and reorganize the diagrams, and perhaps rethink the contents.

In Episode 28, The UML Guy adopted a convention of indicating defects via notes on diagrams, as in this earlier diagram of Driver Use Cases:

Harlan Ellison once observed that a lot of dumb behavior can be traced back to the phrase, “It seemed like a good idea at the time.” Well, Geek Girl has decided that The UML Guy’s good idea at the time is a bad idea going forward. Not that the notes are a bad practice: they clearly indicate the defect, and diagram readers can easily see what the defect is. If your goal is printable diagrams which stand on their own, this might be a good practice.

But it has some weaknesses:

As we find a lot more defects, the diagrams will get cluttered, and it will get harder and harder to arrange the diagrams legibly.
We have to do extra work to show the defect on additional diagrams.
Printable diagrams aren’t your goal, or shouldn’t be, in my opinion. To quote myself:

The Model Rule

We saw The Model Rule in chapter 1; but it bears repeating. To use UML effectively, you should never be simply drawing pretty pictures; you should always be editing an underlying model, using the pretty pictures as your user interface. Thus, the model should contain more information than is displayed in any one diagram; and information in one diagram should not explicitly contradict information in another diagram. Information that is found in one diagram but not in another should not be considered a contradiction. Rather, this simply indicates that the former diagram displays more detail than the latter. Details may be omitted from a given diagram to make it more comprehensible.

But how do you keep these diagrams consistent with each other? How do you maintain the underlying model? This is where a good modeling tool proves its worth: a good modeling tool will maintain the model as you create and edit your diagrams. If you are not using some sort of modeling tool, this very mechanical burden will fall on you, rather than on the machine. That’s a poor division of labor: brains should do brain work and machines should do mechanical work. If you do the mechanical work, you will do it imprecisely and inefficiently, and you’ll have no time for brain work. I urge you to investigate and use one of the many UML tools available. A list of UML tools can be found in Appendix B.

And building on The Model Rule, defect notes on the diagram don’t let your model and your tool help you in managing the defects. As an example, Enterprise Architect from Sparx Systems allows us to add detailed requirements information to each element of the model. Here’s a sample screen shot:

And then you can create a requirements report that lists the defects, as in this snippet:

Launch Car Information System
Satus: Proposed	Priority:	Difficulty:
Phase: 1.0	Version: 1.0
Defect #1: Startup is delayed.

That’s a lot of power to give up just for the minor benefit of notes on the diagrams. (There’s a lot more power in Enterprise Architect reports than I’ve shown here; and if that’s not enough, EA is an incredibly powerful automation environment. You can build add-ins for it, and also build automation clients that control your EA models. I have one in the works that lets you directly create EA models from Microsoft Word 2007 and Microsoft Office 2007. When I first started using EA, I said, “This is a great UML tool for the price!” Today, I know better: Enterprise Architect is a great UML tool for any price!)

So in place of defect notes on the diagram, Geek Girl prefers to note the defects in the model, as above; and then use a stereotype to show that the use case has a defect. I think that’s a better practice, even if it’s a bit tool-specific. It makes it easier to add the additional use cases that Pilot described in this Episode (omitting the domain objects so we can focus on the use cases and defects). And for me, The Model Rule is more important than printable diagrams, by a long shot.

And as for the last item in Geek Girl’s notes: yes, why is H.G. so hostile? That must wait for an upcoming Episode…

Overlooking the Obvious

Martin L. Shoemaker — Wed, 25 Feb 2009 18:10:41 GMT

I just wanted to rename a Word document while I was working in Word.

You know what comes next. In practically every application out there, I have two choices:

Close the app. Navigate to the file in Windows Explorer and rename it. Double-click it to reopen the file.
Within the app, do a Save as…. Optionally delete the old file name.

In both cases, both file names now appear in the Most Recently Used list, even though the old file may no longer exist. Yawn. We know how this works.

But can you learned this? Didn’t it seem a little odd?

Can you remember the first time you tried to teach this to your non-geek relatives? Can you remember them saying, “That’s dumb, that’s confusing”? And then you said either, “But it’s easy enough” or “That’s just the way it works.”

Why is it just the way it works? Because we geeks have spent decades telling ourselves that this is normal. It’s a tradition going back at least as far as the Unix mv command, which can be used to move a file to a new folder but can also be used to rename a file. It’s the same way of thinking – a design way of thinking, not a requirements way of thinking – that says “If we have Create, and we have Delete, then we have Edit, because we can always just Delete and then Create again.” We geeks have just accepted “Save As and Delete” as normal.

Well, it’s not normal. We’re overlooking the obvious: if so many users need to be taught a complicated way to rename a file, it’s because users need a simple way to rename a file! Except in a few superior designed programs, we don’t have a way, we have a workaround. It’s just that we know this workaround so well, we think of it as normal.

Talk about not designing for the user experience! Somewhere right now, Alan Cooper is shaking his head in disgust…

Well, not for me, not any more! From now on, every file-based app I write will have a Rename command right up there with Save and Open; and when you rename, it will clean up the MRU list as well.

Ironically, you know what’s one of my favorite features in Visual Studio? It’s the way you can rename a file in the Solution Explorer, and then it asks if you want to rename the class to match the file, and it just correctly applies the rename everywhere (except in comments).

This is so easy, so convenient; yet somehow, I’ve been overlooking that convenience when it comes to my users. Have you?

You're Selling Software

Martin L. Shoemaker — Tue, 24 Feb 2009 21:33:23 GMT

Update: Fixed a typo and a calculation error.

Josh Holmes has a great post on Return on Investment (ROI). And by “great”, I mean great even by Josh’s usual standards. He worked hard on this one. I was privileged to review three drafts before he published it; and by draft two, I was saying, “Josh, this one’s a winner. I’m going to reference this one a lot.” So stop reading me, and go read what Josh has to say. I’ll be waiting here when you get back.

OK, you’ve read it. Pretty scary, huh? But the scariest part to me is that even though Josh is right, he shouldn’t be. To quote Paul Simon, these are the days of miracle and wonder. To be specific, these are the days of software. I’m not saying this is some grand new revelation; but businesses and software people forget just how much software changes the world. Today, whatever your business may be, you may find that deep under the hood, you’re selling software. Oh, not everybody, by any means. Pastry chefs are still selling pastries, day care workers are still selling child care, and airlines are still selling transportation. But a lot of people who once sold simple goods and services are now selling software, whether they realize it or not.

Let me draw some examples from projects where I’ve worked.

Material Handling

I’ve worked on a number of different material handling projects for a couple of leading companies in the field. This is a long-standing, well-established industry, concerned with moving packages and baggage and loads from one place to another with minimal human effort. If you’re not in the industry, you’ll likely think of it as “conveyor belts”; but there’s a lot more to it. There are conveyor belts, yes, but also…

Rollers
Sorters
Packers
Stackers
Scanners
Lifters
Diverters
Carts

And lots, lots more. But yes, it all starts with the simple conveyor belts and rollers that move a box from Point A to Point B.

Except nobody wants those any more. Oh, not nobody, but not enough customers to sustain the industry. Rollers and conveyors from Point A to Point B are a simple, long-solved problem.

No, what customers want today is a system to take a box from Point A to Point Wherever The Label (Or RFID Tag) On The Box Tells Us To Send It. Point A to Point B requires some human to look at the box, decide where it’s going, and put it on the right conveyor. What the customers want is for the computer to “just know” where this box is going.

And it’s more than that: they don’t want the box to have a label that says “Send this to Shipping Dock A”. No, they want it to have a label that says, “This box contains Order #1232. Send it to the right destination.” And sometimes they even want the computer to look at the box and say, “Well, this box contains 50 copies of The Dark Knight, and Tucson needs those; but the truck to Tucson is full, and Orlando needs 70 copies, so we’ll send them there instead, and then reduce Orlando’s outstanding count by 20. The truck for Orlando is at Shipping Dock C, so send this box there. Reschedule Tucson’s fulfillment for their next truck.” In other words, what customers want is not a material handling system, but rather a decision system that controls material handling.

And if your customers want a decision system, that means you’re selling software.

This is news to most of the material handling industry. After all, the hardware to move all those boxes around might range in the millions of dollars, often tens of millions or more. It may occupy literally acres of space. Parts of it may weigh in the tons. Compared to that, the software seems like such an insubstantial, insignificant thing. Even the cost is insignificant, though you can bet the project managers will complain that the cost is too much.

But that’s because – as Josh points out – they see the software as a cost center. It’s not. It’s a profit center. Without that software, those acres of steel and motors and conveyors won’t move those boxes anywhere. Worse, with bad software, they’ll move the boxes to the wrong places. And so without quality software, customers aren’t going to pay for the material handling systems.

Does that mean you’re only selling software? Nope. No line of code ever moved a single box by itself. The code has value because of the sorters and diverters, and the sorters and diverters have value because of the code.

But the difference is this: the material handling project managers know that the sorters and diverters and other equipment are profit centers. They know they’re selling those. But all too often, software is charged as an overhead or a cost center, not a profit center. So rather than try to sell more and better software, they try to skimp on the software costs, cutting schedules and budgets. And as McConnell has documented, the result is usually longer schedules, higher costs, and lower quality.

The software managers in the material handling world need to read Josh’s post, understand it, think about it, and think how they can express the value of their work. A representative material handling system might cost the customer $20 million. If the software to run that system costs $500,000 to build, then cost-center accounting sees that as $500,000 of lost profit. Management will wonder why it cost so much, and wonder how they can cut those costs. What may follow is pressure and effort to cut costs in ways that make software development take longer and cost more.

But if the software managers can see their group as a profit center and can explain it as such to the executives, then the whole picture changes. When they understand that better software leads to more sales or easier sales, executives will want to invest in better software development tools and practices. Josh gives some good starting points toward that culture change. I would add these observations:

The ROI of software starts with Requirements. Yes, that has become a recurring theme for me. There are good reasons for that. With a foundation of well-defined requirements and a process for accommodating change, software managers can show exactly how much of the customer benefit is directly dependent upon the software. If the system has 100 required functions and 90 of them require custom software implementation, then 90% of the profit of the system is directly dependent upon the software. That 90% is also dependent upon properly functioning hardware as well, so you can’t claim all of that profit as your accomplishment. In the material handling world, I saw a team of nearly 100 assemblers, machinists, construction workers, engineers, and other hardware folks install a system controlled by software written by 10 developers. I think that’s a good rough approximation: software provides 10% of the value of the systems with which it works. (In office systems and other systems not involving device controls, I would say that ratio is more like 50%, maybe higher. This Tablet PC would be useless to me without Windows XP, Journal, OneNote, MS Office, and Visual Studio, which collectively cost more than the Tablet PC.) So in our hypothetical example, the system has a value of $20 million; software is involved in 90% of that value, or $18 million; and software accounts for 10% of the value of those components, or $1.8 million. If the profit margin of the system overall is 50%, then you can argue that the software contributed to $900,000 in profit. These are back-of-the-envelope calculations. A more accurate estimate would require time spent looking at the value of each individual requirement and the percentage of that value contributed by software. But in our hypothetical example, $500,000 of software development costs yielded $900,000 in profit, for an ROI of 80%.
Hammer home the destructive effects of schedule compression, as described by McConnell. Schedule compression beyond about 20% leads to longer, more expensive schedules with more errors and more dissatisfied customers. If the potential ROI is 80%, the actual ROI will be a lot lower if the schedule compression increases the schedule by 50% and the costs by even more. McConnell explains how this happens, and why it’s almost inevitable.
There is a way to cut schedules effectively and productively: develop a true software engineering culture and a culture of quality. There is a better way to build software and systems, but “code faster!” isn’t it. Train your teams to be better developers. Improve your requirements process. (No, I’m not done with that theme yet.) Emphasize defect reduction, not schedule reduction, because defect reduction is one of the most effective ways to reduce the schedule.
Invest for the long haul. Near the end of my first material handling job, the team worked on building a good, well-engineered, reusable and configurable platform that could address a wide range of customer needs. This platform didn’t directly address the needs of any existing customer, so it didn’t receive a lot of management support. Again, this was cost-center thinking: “Why are those programmers wasting money on code we don’t even need?” My second material handling job, nearly a decade later, was with a company which had faced those same issues, asked those same questions, and decided to invest in the software platform anyway. It had some infamous rough spots in its earliest implementations. But by the time I worked there, that baggage handling software was nearly a decade old, and it just worked. Oh, there was always some amount of custom coding for every project; but for the most part, if they knew how many airport docks and how many baggage inducts and baggage claims they had to support, they knew to a high precision how much the software costs would be. And most of those costs were configuration costs. I often said they had Moore’s Law on their side. Moore’s Law says that computing power/speed roughly doubles roughly every 18 months. That means that after a decade of life for that software, server power had increased roughly 128 times; but while airports get larger over time, they don’t grow 128 times in 10 years! The software architecture that was a good solution in 1997 was a great solution in 2007, without any significant upgrade to the software.
Don’t cling to the long haul. As much as I think the baggage handling company was smart to reuse a successful architecture, you must always consider the competitive advantages offered by new technologies. When the baggage handling company did have to make code changes, their reliance on old tools and technologies made every change more expensive. Periodically reassess the value of an existing investment vs. the potential gains of a new investment.

Vehicle Diagnostic Systems

My most recent contract was a project for building vehicle diagnostic systems. One part of the team built the tool that connected to the vehicle bus and communicated with vehicle systems; the other part built the tools that talked to that tool via Bluetooth and USB, and then interacted with the user and with online systems.

Now with a description like that, you might guess that the company knew they were selling software. And you would be right. Oh, it was a mixed hardware-software product, but they were much more clear on the importance of good software than I found in the material handling world.

And yet – while I mean no offense to a great team and some great people that I’m already missing – the organization didn’t approach this project as a software project. They approached it as a manufacturing project.

A typical mass production manufacturing effort boils down to finding and implementing tools and processes to do the same thing over and over, so that you can sell and serve as many customers as possible for as little cost as possible. The rules are different for custom manufacturing; but for mass production, profit lies in reducing the number and costs of the repetitive parts of the production process.

Let’s say you’re building mailboxes. A traditional home mail box consists of a base, a shell, an end cap, a door, a door pull, a door catch, a flag, a flag stop, two swivels for the door, a swivel for the flag, and 21 rivets:

Every mailbox, according to this design, requires a person or machine to put the parts in place and insert the rivets and swivels. If every rivet and swivel can be inserted in one second and it takes ten seconds to align all the parts, then a single worker can assemble a single mailbox in roughly 34 seconds. If instead the shell, end cap, door catch, and base can be injection molded as a single piece complete with a flag stop and indents where the flag and door attach, and the door and pull can be injection molded as another single piece, then that same worker can assemble a single mailbox in roughly 3 seconds.

But that throughput assumes the worker has materials always ready to hand. Suddenly the process is limited not by the worker’s assembly rate, but by other factors: how quickly can you deliver parts to the worker, and how fast can the worker really work without slowing down due to fatigue? Those questions apply to the riveted design as well, but less so: no matter how fast you deliver the parts for the first design, the riveting is the bottleneck.

Once the parts availability becomes the bottleneck, the industrial process engineer changes focus: instead of trying to improve the design of the mailbox, the engineer must improve the design of the process that delivers parts to the worker. Or perhaps the engineer must design an improved assembly process, maybe improved machinery and tools, that will make less work per mailbox. The company makes money on each mailbox built, not on each step performed by the workers. Whatever your cost and effort is per mailbox, that’s a 1-for-1 cost: one unit of labor per one mailbox sold. If you can reduce that unit of labor, you can increase overall profitability and employ more mailbox workers.

So it’s common for industrial process engineers to invest a large amount of effort designing a more efficient manufacturing process. This effort can be seemingly large; but it’s is a one-time effort. Once it’s done well once, it’s done well for all of the mailboxes produced. So the cost of that process design is amortized over the tens or hundreds of thousands of mailboxes produced, and it reduces the overall cost of production for each mailbox.

This is Industrial Process 101; but here’s where the mistake comes in when you see software development as akin to manufacturing. Software development is like manufacturing, in a sense; but it’s like process design, not piece manufacturing!

The software equivalent of the worker assembling mailboxes over and over all day long is users applying the software over and over all day long. The value to the user (and the user’s organization) increases when the user can get more done with less work, and so get more tasks done in a single day. Just as the industrial process engineer creates value by improving the process and reducing the manufacturing cost, so too does the software team create value by improving the software and reducing the usage cost.

But this means that traditional manufacturing process improvement approaches can be aimed at the wrong targets when applied to software development. In manufacturing, it can be cost effective to spend more money on design process improvement to reduce the money spent on manufacturing; but when traditional manufacturing process improvement approaches are applied to software, often the goal is to spend less money on software development. Yet somehow, we expect those “improvements” to improve the quality of the finished product.

Now I’m not saying there’s no room to cut costs in software development. There are inefficient ways to design industrial processes: if your design team relearned basic facts every time they approached a new production line, or they ignored proven practices from other production lines, then they would waste a lot of time and money on lessons learned and relearned. The same is true for software engineering. Indeed, there’s an entire field of study, Lean Software Development, aimed at improving the development process in a similar fashion to the field of Lean Manufacturing.

But simply applying Lean Manufacturing practices to software development can be misleading – even counterproductive – because Lean Manufacturing aims (in part) to reduce the time required for repetitive processes; and in software development, there are no repetitive processes. Oh, that’s an exaggeration, of course, but it’s close enough to true. Industrial process engineers have repetitive processes, such as reading email, filing reports, printing blueprints, etc. In a similar fashion, software developers have repetitive processes, such as reading email, filing reports, compiling code, etc. But in both disciplines, the key work, the important and most time-consuming work, is brain work: thinking about the problems, proposing ideas, presenting ideas, reviewing ideas, revising ideas, etc. And this is work that virtually never repeats! It will repeat if you keep reinventing the wheel; but a good team should know standard patterns and solutions for common problems, so they can concentrate their efforts on the unique aspects of a new project. The truly repetitive processes – checking email, compiling code – are more amenable to fiscal solutions than process solutions. Buy your developers faster computers and better tools: it’s the closest equivalent to getting the mailbox worker a faster assembly tool.

And I’m going to repeat myself yet again: the most productive way to reduce the cost of software development is to improve your requirements process, followed closely by creating a true software engineering culture and a culture of quality. Those are goals of Lean Software Development and are consistent with Lean Manufacturing. Interestingly enough, they involve creating quasi-repetitive processes: standard processes for doing standard categories of work, while recognizing that ideally no work should ever be repeated. A standard way of testing code, a standard way of reviewing code, a standard way of communicating designs: these can add value if done right. However, they can also become straitjackets that prevent a team from solving a problem. I have a lot more to say on the value of quasi-standard quasi-repetitive processes; but that’s starting to veer pretty far from our topic today.

And that topic, you’ll recall, is ROI. It’s easy to figure the ROI of industrial process engineering:

ROI = (New net profit per part – Old net profit per part) * Number of parts produced / (Cost to design the new process + Initial cost to implement the new process) – 100%

This gets slightly more complex when you factor in time: Number of parts produced in how much time? In early usage, you’ll almost always see a negative return, because (as Josh mentions) there is a certain length of time it takes to recoup the initial investment. Businesses will usually set a time horizon in which to estimate ROI: 1 year, 3 years, maybe longer.

A similar calculation applies to the ROI for better software:

ROI = (New net value of work per user – Old net value of work per user) * Number of users / (Cost to develop the new software + Initial cost to deploy the new software) – 100%

But there’s a complication here. In the typical industrial situation, the same company is both designing the new process and manufacturing the parts. The ROI value is more clear-cut that way, because what matters most is the overall bottom line for the company. The same is true for in-house software development; but when you’re selling custom or shrinkwrap software to external customers, the value of the work and the deployment cost are measured by the customer, while the cost to develop the software are measured by your company. That’s a complication, but more of a deal negotiation concern than an ROI concern. The calculation in this case turns into two calculations:

Customer’s ROI = (New net value of work per user – Old net value of work per user) * Number of users / (Cost to purchase the new software + Initial cost to deploy the new software) – 100%

Your ROI = Cost paid by Customer / (Cost to develop the new software + Initial cost to deliver the new software) – 100%

The Customer’s ROI, along with many other factors, will determine what cost they’re willing to pay; and then that value will determine your ROI. You can make educated guesses of what they’re willing to pay, and then use those in estimating your ROI. And remember: just as with industrial process engineering, the initial return will almost always be negative. You have to prepare your arguments for that moment, when it seems like the system cost a lot and is too difficult to use. Is it really too difficult? Or is it just new and unfamiliar? Unless you’re very good at defining and communicating your requirements, users will always see “new” as “difficult”, and then cling to old and familiar; and in the process, they forget that the old was once new and unfamiliar, too. That’s why these ROI calculations include a deployment cost: that’s not just a cost for physically shipping and installing the code, but also for training the users and answering their questions and correcting their early mistakes. And lest we forget: finding and correcting our early bugs, and deploying corrections for those as well.

Conclusion (For Now)

Well, this has gone a lot further afield and gotten a lot wordier than I originally expected. (Regular readers are probably less surprised than I am.) I could go further, discussing ROI for training, ROI for technology upgrades, ROI for requirements analysis, ROI for architecture, ROI for community involvement, and ROI for employee retention. But each of those is a lengthy essay in its own right, and I’ll need some research before I’m ready to tackle some of those.

But I hope I’ve added some personal experience to Josh’s excellent post. Many projects can be technological successes, yet be seen as costly, not as a valuable investment. The difference: do we calculate and demonstrate an ROI? Or do we let stakeholders see only the cost of the software, without seeing the full return on the software?

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!

An Argument for Requirements Analysts

Martin L. Shoemaker — Wed, 17 Dec 2008 00:11:14 GMT

An attempt to trade quality for cost or schedule actually results in increased cost and a longer schedule.

Steve McConnell,
Professional Software Development

What has long been known in other businesses is true for software development as well: if you cut corners for shorter schedules or lower costs, you will get longer schedules, higher costs, and higher defect rates; but if you take the right measures to lower defect rates, you can get lower defect rates and shorter schedules and lower costs. As Crosby wrote, “Quality is free.” But it’s free only in terms of ROI, meaning the investment must be made first; and it’s only free if you first define what you mean by “quality”.

Fortunately, Crosby provided the appropriate definition as well: quality is conformance to requirements. That can be a concrete, quantifiable definition; but in some way it just moves the problem down the road, leaving us to define requirements: not just the term, but the specific requirements of our projects. It leaves us with this inescapable truth:

If we don’t know our requirements,
we can’t have quality.

…we must define quality as “conformance to requirements” if we are to manage it.

Philip B. Crosby,
Quality is Free: The Art of Making Quality Certain

Data from Boehm et al., Software Cost Estimation with COCOMO II

Recent surveys have found that the most frequent causes of software project failure have to do with requirements problems – requirements that define the wrong system, that are too ambiguous to support detailed implementation, or that change frequently and wreak havoc on the system design.

Steve McConnell,
Professional Software Development

Poorly defined requirements are endemic to the software development industry. Boehm’s research on factors that affect development schedules and costs show that:

Excellent requirements analysts can reduce a project’s schedule by almost 30%, while inadequate analysis can increase the schedule by over 40%.

Again and again, schedule pressures lead teams to start developing before they have sufficient requirements definition.

Even though requirements analysis is a key skill, the topic isn’t as “hot” as new technologies and tools that are promoted by vendors and conferences and magazines. And many development teams feel swamped just trying to keep up with technologies and tools.

Martin L. Shoemaker

Data from Boehm et al., Software Cost Estimation with COCOMO II

Among all personnel factors, Analyst capability has the widest range of impact (multiplier range of 2, worst case divided by best case). Teams may tout their application experience as a strength; but application experience has an Influence Range of only 1.51. Application and platform experience combined have an Influence Range of 2.11. Teams would never throw out their domain knowledge and develop for an entirely new platform; but poor requirements practices have almost the same Impact Range.

These teams aren’t foolish, yet they foolishly let a critical aspect of their process get out of control on project after project. A look at their team rosters may give a clue as to why: while there are many roles on the rosters, there may be none with requirements as a primary responsibility. Marketing and sales have requirements responsibilities, but many conflicting responsibilities as well. Lead engineers are supposed to verify requirements; but they are also too busy, and are commonly focused on solutions, not requirements. Designers and developers also focus more on how than on what. Traditionally in software development, analysts have primary responsibility for and are evaluated on the correctness of requirements.

The role of requirements analysts is
to define the problem in a verifiable form,
so that teams may recognize a valid solution.

And next you must ask: who owns that responsibility in your organization? If the answer is "no one" or "I don't know", there's a ripe opportunity to cut your schedules by 30% to maybe even 50%, all while improving your quality.

Code is not enough. It's all about requirements; and that's all about communication.

Ship It On The Side

Martin L. Shoemaker — Sat, 29 Nov 2008 21:59:02 GMT

Curtis Gray informs me that the first Ship It On The Side podcast is now published.Listen to us talk about building and shipping great software while holding down day jobs.

Doctors are the Stupidest Users!

Martin L. Shoemaker — Fri, 21 Nov 2008 04:33:43 GMT

Note to doctors: No, I don't really mean that title. I use provocative titles to get attention and capture an attitude. What? What are you doing? You're going to stick that thermometer where?

Doctors are the stupidest users. If you've ever had to write software for doctors, you've discovered this: the phrase "RTFM" was made for doctors. They just can't be bothered to read even the simplest help docs. They can't bother to learn even simple tools that a bright grade-schooler can master.

OK, that's the programmer perspective. Now let's look at it from the doctor's perspective. On her desk is a small mountain of medical journals she needs to read to keep up with her specialty.

Next to those is a small mountain of textbooks for the new specialty she's trying to learn.

Next to those is a small mountain of new regulations and guidelines she must comply with to maintain her license.

Next to those is a small mountain of insurance guidelines she'll probably never have time to read but should if she wants to make sure she's charging within guidelines.

Next to those is a small mountain of insurance paperwork that demands her scarce attention. She has no time for it; but if she doesn't keep up with it, patients may be denied treatment that would've been approved if she had.

Next to those is a small mountain of accounting statements that she'd rather not bother with, but has to if she wants to pay her student loans and malpractice insurance.

And next to all of those is a large mountain of patient histories, test reports, specialist reports, and hospital reports she needs to keep straight in order to treat her patients.

And somewhere, buried under all of those papers, are a few pictures of the family she hopes to see once or twice this week.

And along comes this programmer person who says, "What's the deal? This is easy! Just read this, and this, and then try this, and learn this, and look at this, and it's easy! You're a doctor. You're supposed to be smart. This should be easy!"

After she schedules the programmer for an emergency barium enema, the doctor goes back to her work.

This is part of the reason (by no means the entire reason) that there's a profession of Medical Technician. These people's responsibility, in part, is to be the doctor's user interface to programs that the doctor just has no time to master. They have time to specialize in arcane software. They usually have more technical experience.

But really: should it be this way? Not that I want to put Medical Technicians out of work; but shouldn't the programmers spend more effort understanding the doctors and their needs, rather than requiring the doctors to understand programs and programmers?

For years, I've spoken and taught about a principle I call Conservation of Complexity. For any given task, there's a minimum complexity required for that class. You can't make it less complex. (But trust me, some idiot can always make it more complex...) If I'm automating that complexity, I take some of that work onto myself, and leave some for the user; but no matter what I do, I can't reduce the complexity below the minimum. And being lazy by nature, I'll want to do the minimum necessary to meet the requirements: minimum complexity for me, and let the user do the work.

But we can cheat! We can't reduce the complexity of one instance of the task; but we can reduce the complexity of multiple instances, especially when those instances are performed by multiple users. In so doing, we can reduce the net complexity in the system.

Let's say the user and I split the complexity, C: I get 0.5 C, and he gets 0.5 C. Now if 100 users do the task 100 times, we have:

Cnet = 0.5 C + 100 * 100 * 0.5 C = 5000.5 C

Cave = Cnet / n = 5000.5 C / 10000 = 0.50005 C

So we've cut the complexity in half. That's great, right? That's why we write code, right?

But suppose some idiot -- i.e., me -- didn't make that app very usable for the user. Oh, it's easier than working by hand, or I won't sell any copies; but say it's 0.8 C. In that case:

Cave = 0.80005 C

So I took an easy way out. The system is still less complex on the whole. We're still winning, right?

But now, let's go the opposite way. Let's say I put in the extra effort to reduce the user's work to 0.2 C. And let's assume this takes me a simply ghastly effort, 2 C. That means that:

Cave = 0.2002 C

By me working twice as hard, the system as a whole works roughly 80% less.

Now these numbers are just examples, of course. But I think they make my point: if all I worry about is getting code out the door, I may not work hard; but my users have to work a lot harder. Too often, we programmers see our perspective too clearly, and the other guy's perspective too dimly. (In other words, we're human.) But the smarter thing to do is to put forth the extra effort to reduce the user's complexity. Because after all, there's money to be made in reducing your user's workload!

I'm reading Alan Cooper's The Inmates are Running the Asylum; and with practically every page, I'm reminded of Conservation of Complexity. And of the doctors.

Also see Joel Spolsky's discussion on mental models. He approaches the same idea: the programmer has a mental model of how the code works; the user has a mental model of how the code works; and great software results when the programmer's mental model is very close to the user's. It's easier for a team of motivated programmers to change their handful of mental models than to change all those users.

Quantity IS Quality

Martin L. Shoemaker — Sun, 16 Nov 2008 00:20:52 GMT

On a mailing list where I hang out, a participant recently said (paraphrased): “He believes that popularity proves quality. I believe that there is almost no correlation between quality and popularity.”

We hear this sort of thing all the time. There’s an implication among self-appointed elites that “the masses” — i.e., everyone who’s not them — just can’t recognize quality. It’s assumed that “popular” is proof that something is bad. You see this attitude in film snobs who insist that an Oscar nomination for The Return of the King is some sort of travesty, because the film is a popular fantasy and not some art house flick or some historical epic. To be fair: you see it in Lord of the Rings fans who for years have been telling others who didn’t like the books that they just didn’t appreciate great literature. And before the films, you could see it among the literati who snubbed Lord of the Rings because it’s a popular fantasy rather than a dreary, post-modern, self-referential, obscurantist yawn. You see it in opera buffs who assume the rest of us are subintelligent because we don’t share their passion for opera. You see it in young rebels who look down on the lives of the conformist “sheeple” and who demonstrate that they are individuals and not “sheeple” — by all dressing and talking and acting and piercing alike. And you even see it in gourmets who extol the virtues of French food over more pedestrian fare like food from McDonald’s.

But the truth is: they’re wrong, every single one of them. They proceed from two clearly false assumptions: that there is one clear, objective, inarguable standard of quality; and that of all human beings, they somehow have been born with/been granted/achieved the unique ability to pronounce what the standard is.

But the fact is just the opposite. If I can avoid butchering the Latin too poorly, de gustibus non disputandum: with taste there can be no dispute. Or in the modern vernacular: there’s no accounting for taste. When someone tries to tell you that his tastes are objectively correct, he’s demonstrating how self-centered he is or how shallow his thinking is.

Does that mean there are no things that are objectively better than some other things? Can’t we all agree that Shakespeare is better than “The Simpsons”? Nope: I could gather up quite a debate on both sides of that issue; and the pro-Simpsons side would be every bit as educated and erudite as the pro-Shakespeare side.

Can’t we all agree that French food is better than McDonald’s? No, for multiple reasons: many people dislike new tastes, and prefer comfort and familiarity; not everyone likes the spices in French food; and if you grew up with French food every day, you might see it as “normal” and McDonald’s as a new experience, where novelty makes it attractive.

And so on, and so on, and so on. If you take any “objective” measure of general quality (as opposed to quality for a particular purpose, which may be assessed much more precisely) and examine it all the way down to its roots, you find personal tastes, past experiences, biases, and other responses that aren’t objective at all. There’s no objective measure of quality.

Except one. See, like many things that are immeasurable in the small, quality is measurable in the large, through statistics. No one person can absolutely proclaim that a certain thing is a quality product; but we can measure with reasonable precision how many people accept and endorse the quality of a product, by virtue of their purchases. In other words, the list writer I paraphrased has it exactly wrong: the closest thing we have to an objective measure of quality is popularity. If a significant number of people enjoy a product, then the odds that you will like it are higher. We’re all individuals, not ruled by statistics; but statistics are a useful piece of information to help you find products to try. Quantity purchased is a valid measure of quality. The market identifies products that the largest number of people accept as quality products.

And before anyone chimes in about betamax, QWERTY keyboards, CDs vs. albums, Microsoft, or any other oft-cited “evidence” that the market can produce the “wrong” answer: go reread my post, because you still missed the point. Don’t force me to go haul out the evidence that shows the conventional wisdom is wrong in every one of these cases, or I’ll produce so much it crashes the server.

Concern vs. Worry vs. Obliviousness

Martin L. Shoemaker — Sat, 15 Nov 2008 23:56:39 GMT

Concern	Worry	Obliviousness
"Has this happened yet?"	"Oh, no, what if this happens?"	"This could never happen."
"How likely is this to happen?"	"Oh, no, what if this happens?"	"This could never happen."
"How can we tell if this happens?"	"Oh, no, what if this happens?"	"See no evil, hear no evil, speak no evil..."
"Can we prevent this from happening?"	"Oh, no, what if this happens?"	"This could never happen."
"What will be the impact if this happens?"	"Oh, no, what if this happens?"	"No problem..."
"Can we prepare for that impact?"	"Oh, no, what if this happens?"	"Cross that bridge when we come to it."
"Can we manage that impact if it happens?"	"Oh, no, what if this happens?"	"Cross that bridge when we come to it."
"Who will be responsible for watching and managing this?"	"Oh, no, who will we blame if this happens?"	"I didn't do it!"
"We'd better do something about this!"	"Somebody'd better do something about this!"	"This could never happen."
"There's nothing to do about this right now, so let's focus on what we can do."	"Oh, no, what if this happens?"	"Looks like smooooooth sailing ahead."

Which column describes your project management techniques?

Disclaimer: This has nothing to do with any of my current projects or clients. The person who inspired this already knows who he is, and is firmly in column 1. Any other resemblance to actual persons or events is purely coincidental.

No llamas were injured in the making of this post.

The Department of Motor Vehicles and Clipboards

Martin L. Shoemaker — Sat, 15 Nov 2008 23:55:03 GMT

All right, I've had enough. It's time for me to issue a decree:

Henceforth, programmers who wish to use the clipboard must be licensed in the same fashion as automobile drivers are licensed by the Department of Motor Vehicles. (Yes, yes, we call it the Secretary of State's Office here in Michigan; but more people know it as the DMV.)

1. Before you may use the clipboard to copy code, you must take 20 hours of classroom instruction on how not to use your clipboard.

2. Before you may be fully licensed to use your clipboard, you must undergo a six-month probationary period during which you may only use the clipboard with a grown up, licensed programmer observing your use of the clipboard.

3. Upon completing your probationary period, you may apply for a clipboard license at your nearest Department of Responsible Programmers. There your code will be examined for any signs of clipboard abuse. (Note: Unlike the tests at the DMV, this examination will not be easy. It will be brutal. You have been warned.)

4. If your code is deemed acceptable by a Responsible Programmer, you will receive a clipboard license, and be authorized to copy code as needed.

5. At any time, your code may be inspected for clipboard abuse. You will receive one (1) point for each line of unjustified code copying. If you accumulate 100 or more points, you will have to return to Clipboard School, or lose your license.

6. If at any time you accumulate 200 points, your clipboard license will be immediately revoked. You will be eligible to reapply after 1 year.

7. If at any time you accumulate 500 points, you will be shot. While we know this is harsh, it's the only economical option. We can't afford the cost of maintaining your code.

8. Clipboarding while drunk is grounds for immediate revocation of your license.

Yes, this means you!