Good enough principle aka enough is enough!

What is good enough?

Good design in Agile translates to meeting the needs for the features that are being implemented right now. This does NOT mean that you should throw good design principles out the window! The software design should reflect what is needed to support the features being implemented, but only what is needed, not what you might need later. In many ways, the approach is counter-intuitive. “Most of us were brought up to strive for perfection,” explained Francois Swanepoel, CTO of Stone Three Venture Technology, “but the fact is that it takes a lot of time and energy to achieve perfection, and the risk is that by the time you do, the thing you have created is out of date.”

Good Enough has nothing to do with mediocrity. It has to do with rational choices, as opposed to compulsive behavior.

What’s wrong with being perfect?

First of all, perfectionism is procrastination. Say it out loud: perfectionism is procrastination. When you try to be perfect, you get little, if anything, actually accomplished. For a project that is in development, perfectionism can lead to endless wanking on a few particular pet tasks of the developers, as they keep trying to make those parts they’re working on better and better. At first it may look like progress, but at some point, those constant attempts at improvement return no value at all.

On the other hand, aiming for Good Enough just gets the job done. In planning, you focus on what the requirements are, no more, no less, and how to meet them simply and efficiently. No worrying about edge cases or making things bulletproof or endlessly customizable — meet the core needs and be done with it. As for development, it should be simple enough to test against the plan to see if a task is met. Once it is, you move on to the next one, and stop worrying about the one you just finished. The work goes by faster, and you accomplish more.

Agile is about embracing and dealing with change. And we all know that change is constant in software projects. Requirements change due to business priorities shifting, or because what we thought we understood really wasn’t quite right. This leads to two problems.

1. Implementing too much foundational code that supports a big design up front makes the software more complex. This in turn makes the software more difficult to understand and more costly to maintain going forward.
2. You will end up wasting time and money developing and testing things that won’t be needed. A design can degrade over time because the requirements dictate changes in some way that the original design did not anticipate.

From my experience, there are some common responses involving the big design approach that is faced with new functionality that is a poor fit for the existing design.

Agile design should be a small investment up front. The team starts with the simplest design possible, develops and maintains an inventory of unit tests and acceptance tests, and continually evolves and improves the design each and every iteration — keeping the design appropriate for the feature(s) developed for that iteration.

From a software development perspective, be good enough with the design, but be great in the other dimensions of software development. Like writing solid, maintainable code that is tested thoroughly and delivered with quality.

Why is the principle of “Good enough” so successful? A few reasons:

• Over- Engineering: A lot of consumers never use all the functionalities that a particular product or services offers. In most usage occasions they only use a fraction of the overall offering. Today’s consumers have realized the myth of over-engineered products and are willing to get for a “Good enough” alternative.
• Accessibility beats Complexity. For a lot of consumer it’s more important to have an easy to use and ready available product or service, instead of spending a lot of time and energy to unlock all the different potential functions that a product might have.
• Value = Low price + sufficient quality. Consumers are more price conscious than a few years ago, so they are thinking twice before making a high price tag purchase decision. These “Good enough” products lower the threshold for a purchase, and they still provide good quality.

Determining what is good enough

There are four core values of Good enough concept: simplicity, correctness, consistency and completeness. Deploy something that makes someone’s life better, something that solves some real world problem. Do it as soon as it’s in a state that allows you and your team to learn from real user’s interactions, collect real data, and collect real feedback. Learn to deal with the fact that users live in the real word — and that world is imperfect.

There are three simple questions you can ask:

1. Is it simple? That is to say, is the design simple and can be picked up by the developers without much work? If the design and implementation is simple, it’s easier to make any needed changes later, while still fulfilling the current requirements now.
2. Does it work acceptably well? If it’s easy for the end user to figure out, and does the job without raising problems the user can’t handle, it’s good.
3. Does it cover all the bases? It should meet the project requirements, with a minimum of additional features tacked on. Wherever additional things are added, it should either be because of (legitimately) changing requirements, or because those features are required by the features which do meet project requirements.

Producing ‘good enough’ products is an art. What I quickly realized was that none of the most intuitive answers actually stand up to scrutiny.

“If the problem is solved, it’s ready to ship.”
“If the client approves, it’s ready to ship.”
“If the audience will love it, it’s ready to ship.”
“If it will be shared, commented on, and talked about, it’s ready to ship.”

But actually, deliverable can be considered “good enough” when:
It successfully solves the problem, addresses the need, or conveys the message intended,
It is clearly and distinctly on brand,
The quality of work is consistent with or above the level of previous work,
It has been thoroughly yet objectively scrutinized by other qualified individuals, and
The final decision of preference had been left in the hands of the creator.

If you work with the user more closely, if you work interactively with the user on a daily or weekly basis, then that user’s going to be able to tell you when it’s time to stop. You don’t let the programmers keep adding features simply because they feel like it would be a good idea. Adding features should be a user decision, not a programmer decision.

Conclusion

One of the mistakes web developers make is to spend too much time perfecting the code base in a project. This ignores one very important fact: you need to get the software into the users hands as quickly as possible, so they can give you feedback. Requirements change, and so do architecture, design, and implementation. Iterative development is the way to go. Deploy something, fix bugs, improve, use revision control, code reviews, code style, testing (if you aren’t testing,you’re asking for trouble) and last but not least, clearly document what you’ve done. Most end users/clients have very little idea what they really want before they actually use the software. Once they get their hands on it, they will be able to give you much more accurate feedback, I promise! :)