Barely good enough doesn't cut it

About a year ago Scott Ambler wrote an article stating, “One of Agile Modeling's more controversial concepts is the dictum that models and documents should be just barely good enough." Scott characterized barely good enough models as having just enough accuracy, consistency and detail to remain understandable and provide value and pointed out that barely good enough is context dependent—what’s good enough for your situation may not be barely good enough for mine.

I don’t like the words, “just barely good enough”. Even after a year, those four little words stick in my craw. I don’t scrape by on barely good enough planning or preparation in other aspects of my life. So why should that be the mantra for my modeling, design or design documentation activities? As a thought experiment, where would you mark a point on the hypothetical value per effort curve below that marks what you consider “just barely good just enough” modeling or design? Now place another mark for where you’d like to be on that value per effort curve for your current project.

I don’t want my checking account to have just barely enough money or get just barely good enough sleep. After a few weeks I’d be a walking zombie or the meanest bitch on the planet. If I allotted barely enough time to get to the airport, sooner or later I’d miss a flight. Since my local movie theatre is just 6 minutes from my door on a good traffic day, I do allot just barely enough time. Most of the time I make it to the movies. (I’m quite willing to trade off having to occasionally go to a later show against sitting through those annoying pre-movie ads.)

In most aspects of my personal and professional life I make choices about how much planning, preparation and cushion or slack I need based on my preferences, style, and the consequences of failure. When things matter I take extra care. When they don’t, well…I’m as casual as the next person. But I prefer to think that I take adequate measures most of the time—adequate and good enough. Not just barely good enough. To me this subtle shift in attitude and outlook is huge. And an appropriate one for agile developers to take.


Barely good enough thinking can too easily be used as an excuse for taking the easier, inadequate way out. Sure, we can discuss what’s “barely good enough” but that missing the point—don’t we all want to do adequate, good work, and not do things that aren’t needed? Barely good enough thinking will always make us question whether we’ve done too much. And as a consequence, any design before coding is getting a bad rap.

I propose we get rid of that barely scraping by attitude and replace it with a healthier one. I propose we start using words like “enough”, “adequate”, or “meets the project’s needs” to describe how much design we do. Or perhaps “just enough” modeling as Susan Burk described in her Practical Process talk at SD Best Practices. These words are far less edgy. But that is a good thing. Without feeling desperate, I’m hopeful people can feel safe enough to start having meaningful conversation about what’s enough given their current situation.

Scott’s edgy phrase emphasizes the point that agilists’ strive to minimize unnecessary work. Design just in time. Do just enough. Don’t go overboard. Push towards minimizing if you’ve had a tendency to over design or document. But I say do an adequate job. Meet your objectives. Maybe you need to do even more designing than you have been doing. Nothing edgy about that message, just common sense.

The “just barely good enough” message can be a real turn off to teams who come from traditions of producing high-quality, high value designs. What? You mean to be agile I should turn away from what I find to be valuable? No, you don’t.

Adequate design means you may need to sort through options and gain enough understanding before you pound out much production code. You may even need to design and build a few prototypes to understand the problem before you launch into something. That’s OK if that's what you need to do. You can be agile without having to barely scrape by. In fact, conscientious developers know that and insist on taking whatever measures they need to build the right stuff.

I have known agile teams who feel guilty about taking any time to model and explore their design options. And they feel inadequate when they find it useful to write down a simple use case to clarify a story card. Good grief! Clarity is what we're after. Others feel not clever (or edgy enough) when they need to think about their problem or sketch out a potential design before writing tests or code. I say stop feeling guilty! If writing, thinking, and talking about your design with others helps you clarify your ideas—keep it up. Most people need to think a bit before they code.

If you want to keep permanent representations of key design or architectural views in addition to their code don’t feel guilty about that either. It just means that you find value in more than simply the working code. (If you don’t, then stop it!) The right kind of adequate design documentation can go a long ways in communicating key ideas to new team members, support and operations. Your code doesn’t always speak clearly to others about your design.

At Software Development Best Practices, Scott gave a talk on agile modeling where explained that barely good enough was the point where the value per effort is maximized. His point on his hypothetical curve is way higher than where I’d mark it. I’m betting your sense of what’s barely good enough differs from Scott’s view, too. I’d label Scott’s point as “optimal” and mark just barely good enough way to the left.


I’m not sure what an ideal value/effort distribution curve looks like, and I suspect a value per effort curve will vary by project type and organization. I’m skeptical that it looks anything like the curve Scott drew (Scott, doesn’t make any claims that he’s discovered a ideal shape for this curve—only that you should find the “barely good enough point” and not overdo design). Curious about various distribution curves and their properties, I took a look on wikipedia. Nothing seemed to fit my expectations. I would suspect that the value of design gradually tails off rather than steeply declines (on most projects). Have you found the value/effort for modeling to follow a normal distribution curve or some other known distribution function? Have you it to vary by project type? If so, in what ways? Do you find that value to decay at some point (after hitting some maximal value per effort point)? Or have you found it to remain steady or keep increasing at a slower rate? I’d be interested in your thoughts.