Defining Success (and Failure)

A Fictional World of Dartopia

Once upon a time, there was a world called Dartopia.

In Dartopia, they organized their culture around a game of darts. Each participant got a dart and tossed it. Each participant waited until the dart landed and then assigned themselves a score of their choosing.

In a famous match, two of the most esteemed dartspeople were engaged in high battle. Regibauld on one side and Bowlina on the other. It was a heated game.

In the final round, Regibauld made a deft toss that shot directly into Bowlina's eye. He chose to award himself a full five marks on the grounds that the dart hit a target that was close and was therefore subject to Limbaum's Law. Bowlina replied by not even tossing a dart, and cited Hattersack's Law for another full five marks.

The matches in Dartopia all ended in draws. For this reason, Dartopia's spectator numbers were extremely low.

Libre Design - a World of Infinite Success

Much like Dartopia, Libre software suffers a critical and fundamental flaw regarding the pursuit of all things design. When a project has no clearly defined metric for success, it engages in a worthless process of guesswork.

As such, much of Libre software succumbs to a ridiculous debate of bikeshedding or opinionated subjectivity, all the while failing to address whether or not a design aids or fulfills the needs of a particular audience.

What is Success?

Success obviously could mean vastly different things to a near infinite number of people. In fact, any project, from the larger collectives with massive codebases to the tiny projects developed by a single person, could define the benchmark differently. Some might define monetary reward as success while others may define it via vaguer notions of audience satisfaction.

The problem here isn't in the diversity of potential goals for success in Libre software, but rather the complete disregard for defining them in the first place.

Without Goals, All Decisions are Moot

We often see only the manifestations or symptoms of this lack of stated goals. Without the vision, it is nigh on impossible to evaluate whether or not a feature is valuable, needed, or desirable. We have all watched threads deteriorate from legitimate discourse into "Well that's that and we are developing it / footing the bill so please respect this choice."

While I applaud such a concrete decision, we should accept the fact that forging ahead and getting things done / committing code isn't a barometer for success[1]. If we don't define the context of success, how is any success even possible?

Instead of two separate parties wandering like amoebas after two different and nebulous ideas, we would have two powerful sets of minds focused in on solving a design problem.

Who Evaluates Success?

In the end, the core of design is quite simple. Dieter Rams defined a loose set of ten ideas that encompassed his perspective on design. One of them is particularly relevant here:

Good design makes a product useful. -- Dieter Rams

Seems obvious, yes? Why then would a world respected designer feel the need to state it? The demon, as always, is in the details. With a focus on Libre software, the questions are clearer:

Who is the software for? Stating "everyone" amounts to "no one", as Havoc Pennington insightfully said.
What are they trying to do?
What feature helps aid that audience to achieving that need?
What feature interferes or confuses that audience?

In light of those questions, we have a solid entry point for evaluating success. If we examine only the target audience for the design, do they find it useful? Why? Why not? What feature aids that particular audience to fulfilling the particular task / need? What feature is not relevant? How does the design of a feature augment or interfere with the given task / need?

It should be stated with the utmost clarity that, in the end, the success of a given design is determined solely by the target audience[2]. All opinions beyond the scope of the target audience, whether positive accolades or vitriolic anger, are irrelevant.

Certainly it is well beyond the scope of a blog article to figure out how to evaluate the success of these types of questions. Sociology has made it very clear that asking a question in a particular way can often trigger a given response, invalidating the information. Same goes for polls and voting. The need to glean valuable information in a meaningful way is the subject of an entire discipline and separate discussion.

In Summary

While reviewing and assessing information can be difficult and complex, it should not dissuade us from forming clear goals to define our success and failure. We need these goals to evaluate how our designs are working. There is likely much value in forwarding some markers for failure as well. A firm set of checks and balances to guide our design, and perhaps more importantly, evaluate the design choices after they are implemented.

We need less mental horsepower wasted on dissonance and bikeshedding and instead directed toward solving design questions. We need less debating over features and more focus on delivering a need to a given audience in a design that suits them.

Success or failure remains in the eyes of the audience, not the creators. Without defining a set of constraints and evaluating our success against it, we can never hope to achieve it.

Let's allow ourselves to succeed by defining it.

[1] There is an interesting side note here in that we are now in the midst of a flamewar over just such a topic. Should our universal metric for success be purely upstream commits? What if we miss the point and consider this an outbreak of tribalism when, in essence, it is purely a different metric of success at hand?
[2] There can be economic forces at play. It is possible to deliver a successful design that has a net sum loss of funds for a company. That too is a design constraint, but is one that is assumed in the creation of the work as opposed to the evaluation post-creation. It also has less of an impact on Libre software design, although the success or failure of a project in terms of its ability to attract participants, does indeed have an impact on development constraints.