A Meeting About a Project

Inspired by Ryan Singer's post, Some solution vs. no solution

Guys, before we move on I'd like to address an elephant in the room. It only just occurred to me to bring this up, so if my thoughts are a bit scattered on this, please forgive me. I know everyone in here has a wealth of experience, but I noticed something in the few previous meetings where this project was discussed that indicates there's room to shed some light on how we should design our software.

There is no best solution, practically speaking. In the couple of meetings we've held to bring some visibility to this project, the agenda almost immediately departed from showing everyone the idea to having everyone (not on the design team, by the way) pitching design ideas about what the best version could be. Unfortunately, in my experience, that concept is a misnomer of software design. There are no solutions to a design problem, and there are some solutions to a design problem. The best solution only exists in theory, because we can't tell the future. No amount of research, polling, thinking, or brainstorming will produce anything appreciably better than one of the candidates from the "some solution" list. What it will do, however, is waste a non-trivial amount of time and perversely conjure the illusion of progress.

For some solution to be possible, it needs to be boxed within a specific timeframe so necessary (and sometimes hard) decisions get made before too much time is wasted on the fruitless pursuit of perfection. This project is conceived out of the desire to find a solution for something we do not currently have. When faced with the difference between not having something in the software vs. having it, there is no such thing as the best solution because any of the available solutions qualifies as the best. It's cliché, but the fastest way to stifle innovation is to bike-shed it by arguing over details of the execution.

You have a design team ready to fill a gap in the product and all you care about is the minutiae of how that gap gets filled. The answer is it doesn't matter how, because 100 times out of 100, having is better than not having. Instead of spending three months analyzing this idea to death, let's ship the goddamn thing in six weeks so we can come up with more of them.

As of today, there will be no more status reports on this project. Everyone here knows the timeframe, what the elements are, and the gist of what we're trying to accomplish. The details will work themselves out as we go, and to ship this on time you need to leave us to it.

Thank you.

Any questions?