The essence of being human is that one does not seek perfection.
– George Orwell

About fifteen years ago, I thought of source code as some sort of “art form”. I actually had a belief that it could
be “perfect”, to a level, and that pursuit of this goal of perfection was somehow important. It was something
akin to believing that software developers were artists that used code as a medium for expression of that art.
The worst part of that belief was that I was striving for perfection “in my eyes”, not those of my users.
Perfection had to do with how the software was implemented, but not whether or not is really was useful. How
utterly naive.
As I mentioned before, business is a blood sport so we’ve discovered that our singular focus needs to be
delivering what our customers value. And they don’t value how software is written; they value what it does, or
more specifically what it does for them. So we focus on relieving pain; which is simply helping developers do
what they want to do, the way they want to do it, but more easily and effectively.
And the ability to do that requires that you listen to your customers and build what they want, since that is the
only thing that they will value. But that’s not the same, necessarily, as building what they need, or specifically
what you think they need.
We have to keep in mind that our customers, not us, are the subject matter experts for what we deliver and they,
not us, get to determine what is valuable and what is not and it is they, not us, that decide whether or not to pay
for the value they perceive.
So, we learned to do our best to get close to what we think our customers want, then we ship it, then we listen to
their feedback, and deliver relentlessly to close the gap between our product’s current abilities and their reality.
And sometimes their reality suddenly changes as does what they value. But when that happens you can’t be so in
love with what you’ve already done that you can’t dump it and start over if needed. Because the code itself isn’t
art and never has been. It’s just a temporary vehicle that leads to the perception of value in the minds of your
customers, and only for a little while.
Watch your market, listen to your customers, be wary of your competition and adapt quickly because the
Eclipse markets belong to only the very big or the extremely nimble.

Since this blog will also be on the long side, I’m going to begin it with the “executive summary” format I tried with my last blog.  So, for those of you that can’t be bothered with “lots of words”, here ya go:

  1. Software that is “good enough” really is
    • Perfection is the enemy of “good enough”
    • “Perfect code” never ships
  2. Ship often, as soon as you have compelling new value
    • Creates a culture of constant improvement
    • Greatly increases value to customers
    • Iterative refinement allows customers to provide feedback
  3. Solve Customers’ current problems
    • Provide a better way, not a new way
  4. Don’t fall in love with what you build
    • Customers don’t care what you value — only what they value
    • Be ready to dump what customers don’t value

Many years ago I thought of source code as some sort of art form. I actually had a belief that it could be “perfect”, to a level, and that pursuit of this goal of perfection was somehow important. It was something akin to believing that software developers were artists that used code as a medium for expression of that art. The worst part of that belief was that I was striving for perfection in my eyes, not those of my users. Perfection had to do with how the software was implemented, but not whether or not is ultimately useful. How utterly naive.

As I previously blogged, business is like a street fight. And to have any hope at beating your opponents you’ve got to focus on delivering what customers value. And they don’t value how software is written; they value what it does, or more specifically what it does for them. For example, since Genuitec is in the development tools space we focus on helping developers do what they want to do, the way they want to do it, but more easily and effectively. And the ability to do that requires listening to customers and then building what they want, since that is the only thing that they will ultimately value.

But that’s not the same, necessarily, as building what they need, or specifically what we think they need. We all must keep in mind that our customers, not us, are the subject matter experts for what we deliver. And it is they, not us, that get to determine what is valuable and what is not. And it is they, not us, that decide whether or not to pay for the value they perceive. So, what we must do is get close to what we think our customers want, ship it, listen to their feedback, and deliver relentlessly to close the gap between our product’s current abilities and their reality. And sometimes their reality suddenly changes, as does what they value. And when that happens we can’t be so in love with what we’ve already done that we can’t dump it and start over if needed.

Because the code itself isn’t art and never has been. It’s just a temporary vehicle that leads to the perception of value in the minds of our customers, at least for a little while.

Perfectionism is the enemy of creation, as extreme self-solitude is the enemy of well-being.
–John Updike

About these ads