Estimating Software Projects:

The art of the SWAG

I’ve explored estimates are important in software projects, and shared my technique for producing an accurate estimate. That technique is detailed, systematic, and can produce fairly accurate estimates. The tradeoff is time: estimation techniques, including mine, require some time to produce any level of accuracy.

Sometimes, though, it’s less important that an estimate be accurate than that it be quick. The canonical example is being asked for a quick estimate during a meeting: e.g., “if we wanted to add 2FA to this app, about how long would that take?” It can be quite useful to be able to give a quick and moderately accurate answer. Generally, a super-accurate estimate isn’t important; the person is just trying to calibrate the level of effort enough to know if it’s an idea worth exploring further.

How do you give an off-the-cuff quick estimate like this? You make a Simple Wild-Ass Guess – a SWAG. The name’s a bit of a joke, but the practice isn’t. You never have to make a SWAG – it’s always appropriate to defer until you’ve had time to make a proper estimate – but if you can make one, and know that it’ll be at least plausible, a SWAG can help cut through a complex debate and keep things moving.

So that’s what the rest of this piece is about. To a large degree making a (good) SWAG is an intuitive process, but I’ve tried to unpack what’s happening in that short moment and give some thoughts about when a SWAG is appropriate, and how to give one.

What’s happening when you SWAG

Done right, a SWAG isn’t a “guess”. Rather, if you’d literally just be guessing, that’s not a situation where you should be making a SWAG. As I’ll discuss more in a bit, the situations where it’s appropriate to give an off-the-cuff estimate are situations similar to ones you’ve seen in the past.

For example, I can make a SWAG about upgrading a codebase from Python 2 to Python 3: I’ve done this work myself a bunch, and observed many more porting projects, and so my intuitive guesses about a new codebase tend to be reasonably accurate. I can’t make a good SWAG in the seemingly similar situation of upgrading a Perl 5 codebase to Perl 6: I simply don’t have enough priors to build on.

So what’s happening isn’t a guess: no, you’re using a highly sophisticated neural network that’s been trained on substantial prior experience¹. When someone asks, “how long with that take?” and an immediate answer springs to mind, that’s the result of some very quick, often unconscious pattern-matching against your prior experience. This is what Daniel Kahneman calls “System 1 thinking”: fast, instinctive, intuitive. (For more, see Thinking Fast And Slow). System 1 can be accurate in some circumstances – including, in my experience, these quick estimates. But only some of them.

When to SWAG

SWAGs can be accurate, but only under the right circumstances. What circumstances are amenable to a SWAG?

Simple, Complicated, or Complex?

First, only certain classes of problems lend themselves to quick estimates. In The Checklist Manifesto (p. 49), Atul Gawande cites research that breaks down problems into three categories: simple, complicated, and complex:

Simple problems […] are ones like baking a cake from a mix. There is a recipe. Sometimes there are a few basic techniques to learn. But once these are mastered, following the recipe brings a high likelihood of success.

Complicated problems are ones like sending a rocket to the moon. They can sometimes be broken down into a series of simple problems. But there is no straightforward recipe. Success frequently requires multiple people, often multiple teams, and specialized expertise. Unanticipated difficulties are frequent. Timing and coordination become serious concerns.

Complex problems are ones like raising a child. Once you learn how to send a rocket to the moon, you can repeat the process with other rockets and perfect it. One rocket is like another rocket. But not so with raising a child […].Every child is unique. Although raising one child may provide experience, it does not guarantee success with the next child. Expertise is valuable but most certainly not sufficient. Indeed, the next child may require an entirely different approach from the previous one. And this brings up another feature of complex problems: their outcomes remain highly uncertain. Yet we all know that it is possible to raise a child well. It’s complex, that’s all.

Figuring out which kind of problem – simple, complicated, or complex – is the first step before making a SWAG.

Simple problems lend themselves very well to SWAGs. I feel very comfortable making SWAGs about simple problems I understand. If I’m asked about, say, adding a new field to a Django model, I’m completely comfortable saying it’ll take less than a day without knowing details. I know the “recipe,” and know that the odds of being wrong are vanishingly low.

Complicated problems can sometimes be given a SWAG, but the bar for prior knowledge is higher. I’ll sometimes make SWAGs about complicated problems, but only ones that are good matches to problems I understand. For example, take adding SAML authentication to a Django site. This is a “complicated” task: different SAML providers work differently; there are some non-obvious problems to be solved integrating SAML users into Django’s user model; and so forth. But I’ve done this a few times, and know that although the “recipe” is longer, it’s still finite and defined. For most Django sites, it’ll take a week or two, or a month at most.

Avoid making SWAGs about complex problems. Pattern matching doesn’t work on these problems, regardless of how many similar problems you’ve solved in the past. For example, imagine I’m asked to get a Django app’s availability up to 99.9% uptime. “3 nines” is an achievable target, one that I’ve hit (and exceeded) before. However, availability is complex: the limits to availability differ from app to app. Factors include the app’s architecture, its choice of backing data store(s), the cloud infrastructure, coding quality, testing standards, deployment and operational practices, and more. Without knowing a lot of details, a SWAG would be more likely to be wrong than to right.

Pay attention to intuitive negative emotion

If you’ve been asked for quick estimates a bunch, you might have noticed that sometimes the request triggers negative emotions: fear, anxiety, confusion, etc. You get that sinking feeling in the pit of your stomach. “Oh crap”, you think, “this is not going to be easy.” For me (and most experienced software engineers), there are certain kinds of projects that trigger this feeling. We’re still pattern matching, but now we’re noticing a certain kind of project that resists estimation, or a kind of project that is likely to go poorly.

Some of the kinds of projects that are likely to be “complex” and trigger this “oh crap” feeling for me are:

• Projects where the user flow isn’t obvious or well-scoped. I’m not advocating for waterfall design, but if there open questions that can only be answered by user research, it’ll be nearly impossible to predict what that research will reveal.
• Technical situations that I know will include lots of complexes, hidden problems –ones that are unlikely to reveal themselves until the project is well underway. In my experience this includes
  • complicated authorization schemes
  • high availability or performance requirements
  • increasing scale (traffic, data storage, etc) of more than a couple of orders of magnitude
  • complex technical transitions (e.g. switching programming languages or cloud providers)
  • complex re-architectures (e.g. moving from a monolith to microservices)
• Projects where policy decisions will substantially drive technical requirements, especially those where the policy is unclear or not yet written.
• Work that requires an audit (e.g. many compliance regimes), or similar situations where the complete TODO list isn’t known until some external party provides it to you
• Projects with many stakeholders, especially ones that are somehow external to the project
• Fixed deadlines or budgets – more on this below.

This isn’t an exhaustive list; merely the kinds of projects I’ve seen go sideways in the past, and thus deserving of a legit estimate instead of an off-the-cuff one. You could probably come up with a similar list from your experience. The key point is to listen to those intuitive negative emotions. If you get that “uh oh” feeling, it’s almost certainly a time to slow down, engage System 2, and invest the time in producing a well-thought-out estimate.

Watch out for Iron Triangle constraints

Another situation I recommend avoiding SWAG estimates are ones with what I’ve come to think of as “Iron Triangle constraints.”

For the unfamiliar: the Iron Triangle is a model for the constraints inherent in project management. At its most pithy, the Iron Triangle can be summarized as:

“Good, fast, cheap: pick any two.”

(In practice, sometimes “any two” is optimistic – sometimes you can only pick one!)

In many real-world cases, one of the “legs” of the Iron Triangle is non-negotiable. Some projects come with a fixed timeline (“we need to announce our new products at the big conference next quarter”). Many come with fixed budgets: the team you have is the team you get; no new hires or contracts are going to be approved. Sometimes quality is non-negotiable, as in the case of company-wide SLAs/SLOs, or compliance requirements.

Constraining any of the “legs” of the Iron Triangle magnifies project risk. When something goes wrong on an unconstrained project, you’ve got options – spend money to meet the timeline; cut features to save the budget; extend the timeline to meet requirements. But when one (or more) of those “legs” are constrained, a small problem can turn into a disaster quickly.

In these situations, SWAG estimates can be dangerous. It’s worth the time to produce a full one.

How to SWAG

In practice, what I’ve spent the last 1500 words describing happens in a heartbeat: someone asks “hey, how long will that take?”, you very quickly decide if it’s a safe enough situation to make a SWAG, and then you make the guess. If the project is simple enough, if there aren’t any red flags, and if the project is one you recognize enough to have an intuition about: SWAG away!

Which brings us to: how should that guess sound?

Express your guess in orders of magnitude – “days”, “weeks”, “months”, or “quarters”. I’d avoid any estimate under a few days unless you’re sure it’s a simple task and you’re highly confident in the timeline. Similarly, I’d avoid any estimate longer than a couple of quarters – that’s just too long a timeline to have any degree of certainty about. An exception is if you’re trying to communicate that something is stupendously time-consuming, where you might say something like “that’ll take years” to try to hammer home the scope.

You should also deliberately sound vague and squishy – don’t pretend at false precision. An answer like “15 days” pretends at a level of accuracy that’s impossible without more careful estimation. Something like “a few weeks, maybe two or three” expresses the right level of uncertainty. You can also explicitly mention that you’re not sure, or express a rough level of confidence. Words like “maybe” or “I think” or “perhaps” are useful, as is a questioning tone (e.g. a rising tone, or a literal “?” if this is in writing).

This might sound something like one of these:

• “several days, I think, probably no more than a week”
• “a week or two, possibly three”
• “we might be able to have that done by the end of the month, but I don’t feel super-confident about that”
• “well, we can have some features done by Dreamforce, sure, but probably not all of them”
• “that’ll take a least a month, probably longer”
• “that’s a ‘sometime next quarter’ sort of timeline”
• “if nothing goes wrong, a month?”

And so forth.

If it’s important, follow up with a proper estimate

Now that you’ve given your SWAG, you’re not quite done.

Sometimes, the guess is all that’s needed. Someone asks, “Hey, can we do the thing?”; you say “that’ll take several months”; they say “nah, never mind.” Or, you do decide to embark on the project, but the specifics aren’t very important: you said “a couple of weeks” but if it turns into three or five, nobody will really care.

But if the estimate is important, if there’d be a problem, even a minor one, if you were wrong, you need to follow up. If you’ve said something like “yes that’ll be done in time to present at the conference”, you better go back and make a proper estimate to confirm your SWAG. Once you’ve done that work, you can then follow up, letting folks know if your estimate will hold.

Phew! I thought this was going to be a quick follow-up to my previous piece about making real estimates, but it turns out that writing about intuitive processes is hard! I hope this has helped unpack some of what’s going on when we make these sorts of guesses and given you a framework for using them in your work. If you make a SWAG, and it goes well – or poorly – I’d love to hear about it. Let me know!