A common approach to problem solving is to consider it binary. Either you’ve fixed the issue or you haven’t. Some problems fit that domain well: Either the calculator returns 2 on 1 + 1 or it doesn’t. There really isn’t much of a middle ground.
But many problems in product development aren’t like that. They’re far more hazy. Solving a problem in 100% of the cases for 100% of the people might very well not even be possible. So thinking of such problems as binary flips is not only futile, but harmful.
A better way to think of hazy problems, like “how easy is it to get started with Basecamp?” or “is the query interface for Active Record as readable as can be?”, is to focus on mere progress instead: Are we making it better?
That’s such a disarming question to pose of new initiatives. No longer does an idea have to contend with being The Solution, it simply has to contend with making things better.
It makes it so much easier to find consensus that way. Everyone sits with their own idea of The Solution, but most people can agree whether A is better than B, when both of those states are real.
Compare the concrete, make it better.
Hank
on 04 Feb 15@DHH
Speaking of “making it better”, I’ve emailed Support now multiple times of the last few weeks to report a simple bug and haven’t seen it fix.
When you go to the overall system status page
https://status.basecamp.com/
And you then click on the Highrise 12 month status detail, this link fails:
http://highrisehq.com/uptime
Matt Henderson
on 04 Feb 15The issue that sprang to mind when reading this, is that of local vs global optimization. The benefit of working towards better is that you’ll eventually get to right, but I suppose sometimes it’s also important to step back and assess how far that local right is likely to be from the global right (if such a thing exists).
Jon
on 04 Feb 15a great way of framing a tricky problem, @ matt a great addition.
denis
on 04 Feb 15The caveat is that you must still do this the right way… I can write a ton of spaghetti code to make something better but such a quick bandaid solution isn’t usually appropriate
DHH
on 05 Feb 15denis, “making it better” needs to be considered across all metrics of improvement. Make the code base worse by taking on a bunch of technical debt doesn’t clear that bar.
This discussion is closed.