Interesting conversation from MacStories today.  A feller says he's leaving "Things" because it's not changing enough, not because it's incompetent.  There's an important section in Lopp's post about leaving "Things" that the conversation seems to gloss over: Lopp says he's found a better alternative.

Regardless, the topic of the conversation itself is exceptionally useful.

Should customers appreciate polished software?

Here's part of a reply from Daniel Jalkut to Lopp called Stagnation Or Stability? from Bitsplitting.org:

He applauds the app for allowing him to do his work โ€œfrictionlessly.โ€ How does a software developer achieve this level of performance? By first building a quality product and then working deliberately over months and years to address the minor issues that remain. Woodworking makes a reasonable analogy: after a chair has been carved and assembled the job is functionally complete. Itโ€™s a chair, you can sit in it. Itโ€™s done. But customers will gripe with good cause about its crudeness unless the hard work of detailing, sanding, and lacquering are carried out. Only then will it be considered finely crafted.

As a seasoned software manager, I know Lopp appreciates how hard it is to achieve the stability Things has provided for him. But as a user, heโ€™s as excited as any of us to see new, fresh designs. As an onlooker, itโ€™s easy to associate dramatic change and motion with competence, and quiet refinement with laziness. We must draw on our own experiences attempting to build great things to appreciate how much work takes place in stillness, to have faith that even though things may appear stagnant, a benefit of frictionlessness is resulting. An app at rest may be in that long, arduous phase of becoming finely crafted.

So the problem here seems pretty clear -- reusing Jalkut's metaphor perhaps a bit too much, let's say that the "masses" are often happy to have a rough-hewn chair.  More importantly, they'd rather have a rough-hewn chair NOW WITH ROUGH-HEWN TABLE!!! than a wonderfully crafted chair.

Many people make do with a Chevy even after they can afford the Benz.  Not everyone buys the latest iPhone.  Etc etc.

So let's flip the question:  

Should programmers appreciate that customers don't always want (aka, "pay for") polish?

Why do developers -- and not just developers, but, in my experience, the better developers -- seem to strive for perfection without a clear business case?  Look, let's not get confused.  I want polished code, business be damned.  But I can also understand the argument that we can't enter the table-using vertical without, well, a table.  And if that means our chair is a big ball of mud, all I can really do is suggest that we're going to have a hard time catching up when someone creates polished chairs and tables down the line.

But until that happens and our products are outflanked, no matter how much Little Red Hen I try to be, I'm just Chicken Little to upper management.  The worst part?  I don't know that they're "wrong" to prefer the rough-hewn chair, just like Lopp does here.

More to the point, how do you know when your chair has enough polish that it's time to move on?

Labels: , , , ,