Blogature

I was chatting with Brian from AlwaysBeta last week about web application deployment strategies. He was worrying over setting one up, and was curious what Jon and I have been doing for Thinkature. We’re aware of nice systems (like Capistrano, née SwitchTower), but just haven’t invested much time in setting something like that up. I hadn’t really realized why we were deferring this particular issue until Brian asked about it, and it struck me that this was a pretty common pattern in how we make decisions of all kinds here. If we don’t have to make a decision about something now, we defer it until we have more information about the issue.

This happens all the time for us. Like, consider the design of the import/export functions. We know we need them, we have some ideas about how we could do it, but we don’t know what the Right Way is. So, we defer. We figure that we could make something up now, but the odds are pretty good that we’ll have to rewrite it later because we didn’t really understand the surrounding issues. But we know that over time, we’ll know more - Thinkature members will let us know how they’re using the site and what kinds of features would be most useful for them. Same for our deploy system. When we first started, we didn’t know what our deploy process would look like, so we just winged it. Now that we’ve deployed a bunch of times, we’re generating a clearer picture of what the right deploy system for us would be, and when we set one up, it’ll be just right.

This works on a macro scale, too. The release early, release often mantra (dissent) is really the same idea - defer what design decisions you can until after you have people using your site. Same goes for business models, too. YCombinator’s motto (well, one of them) is “make something people want,” with the sub-motto “and the business plan will work itself out” - again, defer an important design question (your business plan) until you have the data you need to do a good job with it (what your product actually is and how people use it). Certainly, you sometimes have a very clear picture of those issues before building the product, but in this particular area, it’s pretty common to not be sure, cf. reddit, delicious, myspace.

Another corollary of this idea is the classic “premature optimization is the root of all evil.” Optimize when you know what matters in your application’s performance. Doing it any earlier is a waste of time. Defer, defer, defer.

Maybe this was obvious to everyone else already. It’s certainly not a new idea - it sounds like it might have something to do with the formal iterative design processes like Scrum and XP (topics I don’t know much about). It might also be the gist of “grey thinking” from this book, but I haven’t read it, only heard about it second hand from people who have.