Methodology Design: The Way We Do Things Around Here

Date: Dec 30, 2005

When people talk about "improving" software methodology, they rarely talk about tradeoffs. Requirements freeze, for example, runs the risk of delivering exactly what the customer asked for - and not what he needs. Concrete, detailed estimates take a considerable amount of time to create, and that's time that could be spent writing code or executing tests. Matthew Heusser discusses the tradeoffs and choices you'll have to make when the goal is improving (or even initially developing) your methodology.

You might be coming back from the big meeting where the boss announced the methodology improvement program. Perhaps the subject showed up at your annual review as a "goal" for next year. Or maybe you’re the boss, and the subject keeps coming up in leadership meetings. It doesn’t really matter. The point is, you’ve got to improve your software development methodology.

Whatever that means.

Let’s face it—a software development methodology is just a fancy term for "the way we do things around here." Saying that you want to improve the methodology doesn’t really mean anything. There are piles and piles of factors in software development; simplicity, reliability, performance, fitness for use, response to change, accountability, speed, defect ratio, customer satisfaction, "making sure you pick the right projects," or "making sure you run the projects right"...the list seems endless. To reduce the "goodness" of your process to a simple one-dimensional statement is somewhere between immature and unethical.

At the same time, it is possible to improve a specific attribute of the way we develop software—for example, to make delivery dates more predictable, to make the state of the project more visible, to improve overall development speed, or to more easily respond to changing demands. Specific attributes of the methodology can be improved.

What the Textbooks Don’t Say

Tradeoffs are not just something you have to deal with now and then; methodology in design is all about tradeoffs. For example, if the organization wants accountability and predictability, it may require documented requirements with various levels of review and signoff, and create a change-control board with the power to line-item veto changes in requirements that may affect schedule.

Everything sounds good so far...until about six months later, when the VP of New Product Development can’t get the feature set changed in order to respond to a market demand. Some ninny down in software engineering is holding up the company’s ability to deliver products to customers, all in the name of "process improvement"!

Then again, perhaps you work in a stable field where the requirements don’t change much—such as defense contracting. In that case, locking down changes might be exactly what the organization needs.

My point is that improvement in software development must be subordinate to the needs of the business; the key is to trade away problems that bother the organization for problems that don’t. As SourceGear CEO Eric Sink puts it, "You can’t eliminate problems, but you can make trades to get problems that you prefer over the ones you have now."

Consciously or not, the trade is going to happen. If done unconsciously, the team could very well end up in worse shape than when it started. Then again, sometimes the organization wants everything: Predictability, accountability, visibility, and the ability to respond to change. In that case, either some genius is going to innovate something (more about that later) or else the system will find some tradeoff you haven’t thought of yet—probably something that’s hard to measure. In the case above, a constant pressure to meet mutually exclusive goals could lead the team to work on only those specific measures, ignoring the support they historically gave to the sales department. When the sales department has to cancel a series of web-based-meetings because they can’t figure out the system, costing the organization six months worth of sales leads, your raise, your bonus...it’s really hard to call that process improvement.

Since it’s better to make tradeoffs consciously, let’s talk about a few of the most common ones.

Descriptive or Prescriptive?

The first question, the one the textbooks often skip, is how you think of the methodology: Does the model describe how things are generally done around here (descriptive model), or does it tell the staff exactly how to do the work, every time (prescriptive model)?

Authors of descriptive models have given up on planning exactly how each step should go, and are relying on smart people to make good choices in the moment. Still, new hires need somewhere to start, so descriptive models can be very helpful to them. They tell the new employee what’s expected and give a sample flowchart. A descriptive methodology might talk about what-how-build-use, or perhaps say that the organization creates a simple working system and builds features, or talk about the importance of prototypes or customer signoff. A descriptive model is supposed to model how work is actually done, so it might go so far as to say "We do X when we think it has value" or "We tend to do Y on smaller projects and Z on bigger projects." Descriptive models have drawbacks; cowboy developers can ignore them and create risk.

Prescriptive models, on the other hand, tell everyone exactly what to do and when. They tend to be large, require a lot of documentation, and are expensive in terms of person-hours to create. Prescriptive methodologies are essentially "project insurance"; your team pays a price of inefficiency now in order to mitigate or avert a disaster later.

So here we are, just discussing what a methodology is, and we’ve got a tradeoff.

Estimates or Code?

If there was ever a no-brainer for improvement, you might think it would be "Gather estimates before you code." After all, business people count on return on investment (ROI), and to do that you need to know how expensive the project will be!

The problem here is that nothing is free. Meaningful estimates take considerable time to produce; you have to have relatively solid requirements and almost have a complete design. If the organization has 20 projects for which it wants to calculate ROI, the development staff could find that it’s spending as much as 50% of its time just estimating. Last time I checked, companies expect developers to actually create software, not just quote it.

Estimates are a good thing. But time spent on estimates is typically time not spent on project progress. My questions are along the lines of "How do we balance between quality of estimates and the time spent to make them?"

The Agile movement gets away from this problem by just listing work in orders of magnitude, creating a simple working system, comparing estimates to actuals to create a ratio, and then predicting delivery. Notice that to get to that point, they trade away predictability, which may be fine for this project—but when should we plan on the next project starting?

Delivery Date or Features?

Again, the Agile movement comes to our rescue by asserting that the software should be built as a simple working system, with features added in a priority determined by the customer. By bringing the code up to shippable quality very often, it’s possible to pick any ship date from the outset, and hit that ship date.

You just won’t know exactly what features will be delivered on that date.

The alternative is to insist on a very specific feature set, which means that predicting the date is out the window, unless you’re willing to either sacrifice quality or have heavily padded estimates.

Control or Productivity?

Most software managers like to plan and to control; loss of that control implies fear or weakness. When people are not in control of their own destiny, and every choice is stripped from them, productivity suffers. There’s a great deal of research showing that the dehumanizing nature of some elder-care centers causes people to give up hope; human life systems simply stop working when life becomes a prescribed ritual without individuality.

In the development world, people usually don’t die—they just complain a lot and work slower. If you’ve ever seen a half-dozen people drawn into an hour-long conversation about how silly a policy is, you know what I mean—imagine if those people could have been working instead!

The best way I can describe this principle is to tell you about my daughter, Kathleen. Katie is three, and if I tell her she must do something, well, she may do it, but it’ll probably be lunchtime first...or dinner...or bedtime. So instead of orders, we focus on giving her choices: Do you want to wear your coat or carry it with you? Do you want to brush your teeth before or after bath time? Sure, you can stay here now, but then we won’t have time to go to the playground later....

I’m convinced that a great deal of the talk about having developers "sign up" for projects, work, or sit down with customers to discuss "story cards" is simply an application of this principle.

Organic Decision Making or Mechanic?

I’m going to borrow a line from a wonderful blog at the Rands in Repose site:

Mechanics move forward methodically. They carefully gather information in a structured manner and store that information in a manner that makes [it] easiest to find again. They quietly observe, they stay on message, they are comfortably predictable, and they annoy the hell out of Organics.

Organic decision making is gained from a informal communication system: conversations you overhear in the company bathroom, the body language and tone of voice people use in meetings, what you’ve managed to Google on the Internet. Mechanic decisions are made through a systematic process that’s probably documented.

Mechanic-style decision making can take a long time or a lot of consensus, and may lead to over-engineering the solution. Organic decision making may be quick, may be wrong, and often lacks clear documentation on why, when, or by whom a decision was made.

These two examples are extremes; most people act somewhere in the middle. Which extreme would be better for your organization?

The Place for Innovation

Most of the time, methodology design is about tradeoffs, but there are some innovations that really change things. When Johannes Gutenberg invented the printing press, he made printing better, faster, cheaper, and more predictable. Encouraging your people to improve their writing and analytical skills, to find and use better tools and more powerful languages, or to have a better sense of personal excellence and craftsmanship can improve "the way we make software around here" without much work.

That’s basic leadership; it’s surprisingly rare and very easy to get wrong. It also requires that the staff have time to think and an environment in which they’re allowed to experiment, which means a loss of control.

So, while it’s possible to improve in all factors of development, you may have to give up some predictability and control now in order to get speed later. Even if you can give up some of those things, however, the next logical question is how much?

My Personal Tradeoffs

We’ve barely touched the surface of the tradeoffs involved in method design. At this point, many people just want an answer. Sadly, I can’t tell you how to lay out your methodology; I’m not in your shoes. I can, however, tell you that I’ve spent my entire career in commercial, non-government software development, and in that time period I’ve learned the following truths:

Given a choice, my customers are generally happier with working software than with comprehensive documentation.
My projects change so rapidly that comprehensive documentation is often a waste of time.
Written requirements with developer review has worked well for my teams.
Estimates done by someone who isn’t going to do the actual work are a serious cause of friction.
Simple working system + customer-prioritized features works.
Time spent on "process improvement" could often better be spent on skills improvement. After all, you can have a wonderful process description for how requirements are gathered, but if your analyst doesn’t have basic analysis and writing skills...you’re horked.

The answer to most of these tradeoffs is not going to be A or B, but some balance between the two that’s appropriate for your organization, your customers, in your context. I’ll leave you with just one piece of advice on how to get started: First write down what your organization actually does now, even if it’s just "I write a spec for Bob; he disappears into the server closet and comes back after a couple of weeks." After that, don’t try to develop the perfect-o-rama software methodology; instead, make small changes, one at a time. The pain of change will be less for everyone, and you can take pride in each inch-pebble change. If software methodology is a product, remember:

Simple working system + customer-prioritized features works.

Oh, and one last thing: Try to have fun.

Matthew Heusser actively develops working software and also writes and speaks on systems improvement. You can email Matt at Matt.Heusser@gmail.com, or visit his web site. He would like to thank Sean McMillan for his feedback on this article.