Software developers love to solve problems. The rush of solving problems is what gets us out of bed and onto our keyboards in the morning. It feels great and is inherently motivating. If you're managing a true software developer, you never have to worry about motivating her to work.

In today's environment that passion is being met with boundless infrastructure, open source tools, and endless supportive tutorials, all available for free or low cost on the Internet. Combine that with a business environment in which software is eating the world and Silicon Valley is churning out new software businesses faster than the Cambrian explosion generated new species and you get an intoxicating emotion common in many software developers today:


Ambition is great and drives us to build great things, including large amounts of software. People who are serious about building large software projects sooner or later come to terms with the only real limiting factor we have (it's not money, creativity, nor demand. Can you guess what it is?)

The only real limit to creating ambitious software is efficiency.

I've touched on this already in The Importance of Working Software. In this article I'm tackling it from a different perspective.

What is efficiency? You can think of it as a simple formula:

efficiency = value / waste

Great, now we know what efficiency is, but what are value and waste? That's a deep topic that I'm not going to do justice to here, but let's take a peak at the value side.

For a typical software team, a lot of their time is spent trying to answer either the question, "Why isn't this working?" or "What is this code supposed to be doing?" We're looking for a source of truth to answer these questions. You can think of value as the source of truth. Value is like the North Star, guiding us to where we need to go and away from waste. OK, but where does value come from?

Value comes from customers.

By its definition (which we're not getting into here), value comes from customers. If you have a customer, you have a source of value. It takes practiced skill to discern it but you can feel confident that it's there. If you don't have a customer for the problem you're working on then you're sailing without a compass.

Be Tenacious When You have a Customer

If you have a customer for the problem you're working on then you can feel confident that you're going in a good direction. Be tenacious in solving the problem. Present your solution to the customer and ask whether he's satisfied. Repeat the process as fast and as often as you can while you have a willing customer.

Be Careful (not Tenacious) When You Don't Have a Clear Customer

What does it mean not to have a customer? It's worth sitting for a moment to consider the question. Here are some common possibilities:

  1. You are the customer. This is one of the most dangerous (and common) situations to be in if you're working on a product or an open source project and you're not writing the code only for yourself. If you don't think of yourself as the customer but you're not in communication with one, then functionally you are acting like it. Because writing code is so much fun, and because most of us haven't been taught the skill of choosing a customer and discerning value from her, we tend to plunge ahead and rationalize that we're writing our code The Way It Should Be Written. Code that's The Way It Should Be Written is obviously correct for all cases and when customers eventually come into contact with it they will see The Wisdom of Its Correctness. This is the path toward the dark side, the path toward waste.
  2. You have customers but you're spending more time telling them how to use your software than you are asking them what they want it to do.
  3. You have customers but you don't have direct, easy communication with them and one of your teammates plays the role of a customer, intentionally or accidentally. This is a really interesting case and worth fleshing out.

When You Play the Role of a Customer

Normally software developers on the team make for horrible customers because their minds are biased by their knowledge of the implementation. They naturally want to design the user interface (or UX) to minimize the implementation costs because they spend all of their time thinking about the implementation mechanics. Unfortunately, the optimal design for supporting the implementation is rarely the same as the optimal design for supporting the user; they're subject to different requirements. A colleague of mine who worked at Microsoft once told me they would never let the same developer both design and implement a feature for this reason.

Sometimes a developer can make for a good customer stand-in, such as when she's joining a team for the first time. During this time she's ignorant of the implementation mechanics so there's a window of opportunity for her to play the role of a customer. This is a golden opportunity! Another opportunity arises when a developer is surprised by how the software operates. This is in part because of the importance of the Principle of Least Surprise. You can't optimize to minimize surprise unless you have surprise to minimize, so when a team member is actually surprised by something you should jump on the opportunity to explore it.

In both cases you should treat the mind of the developer like a clean room. Be careful not to contaminate it with knowledge of the implementation while you carefully explore her mindset. Ask her what she was expecting the software to do, what it did instead, what felt easy about using it, what felt hard, what she wanted to achieve and how the software could better support her goals. Have another developer make improvements to the software and then ask her to use it again. Avoid discussing the implementation with her until the improvement process is complete. At another time she could play the role of implementor while another developer plays the role of the customer.


When we make software for anyone other than just ourselves, we are following an invisible muse called value and doing our best to avoid creating waste. Some tools (such as Test Driven Development) help to make value more visible, but the best situation is when you have direct access to a customer making clear requests. In this situation, tenaciously solve problems like a bulldog while racing forward like a greyhound. When you don't have a clear customer (or you are playing the role of the customer yourself), your value signal is weak and risk of generating waste is high. Tread cautiously and carefully like a bloodhound until you've once again found the scent of the value you're hunting.