At first glance, two posts on successive days from the smart folks at 37 Signals are in opposition.
First, there is “Do Fuss:”
Spend the time. Put forth the effort. Make it great.
(snip)
Well, if it’s just a little thing, then fixing it is just a small matter!
In other words, details matter and are worth the effort. I agree, even when I can’t live up to the ideal.
One day later, a different member of the 37 Signals team explains why simple features are not always such “small matters” in Revealing hidden assumptions in estimation:
Imaginary work is always easier to do than real work.
(snip)
Next time you find yourself thinking something ought to be simple to do–whether in a project of your own, or in someone else’s–pause for a moment. What assumptions are you missing? What real work are you overlooking because the imaginary work is so much more attractive?
I’m happy to give credit to 37 Signals. I use Tadalist quite happily, and hear good things about the other applications.
Still, I think I think the posts, in combination, demonstrate a push-and-pull in play. “Do Fuss” is aimed at other developers, ostensibly, but may be applied far beyond software. “Reveal…” speaks to developers’ tradeoffs, but feels like a warning to customers, too.
I guess I’m asking… do you want us to make a fuss or not? Or only about our own work, not yours?
That’s not a fair question, of course.
Remember, though, people make a fuss about things they care about. Customers who make a fuss do so because they have a frisson of recognition when using an application that in some fundamental way matches their expectations or needs. (Even the needs they didn’t know they had until that moment!) That recognition is rare enough, I think, that it inspires incredible excitement. You feel “Finally, someone who understands me and the way I work/play/create/consume.” However, all customers move quickly on to the next stage, which is “if it only did _____, I’d really be happy.”
In most scenarios, only that second stage gets communicated to the developers. But the second stage is never reached without passing through the first stage. Developers must remember that process, and hear the (too often) unspoken thrill their customer felt in the first stage in the background of their complaints, nudges, and requests in the second stage.
Developers should fuss about their work, and be glad someone else fusses about their work, too.