I’ve since become convinced that this process is in fact the best way to design any code, not just DSLs. API? Write out how you want to call it, then write the code that responds to those calls. Routing in a web app? Write out the URLs you want people to hit, then create the code and routes that will make those work. A web page? Design the page, build it out into HTML, and then write the code that makes it live. Each of these is an example of design-first development.

You may be wondering if I’m abandoning the lean/agile fold for waterfall with this idea. Happily, I’m not. If you think about it, this is how TDD (or BDD) works: you write a test or spec that runs some code (in the process, designing how you’ll interact with the code), and then you write the code that makes it pass. The sort of design I’m talking out isn’t fossilized in spec documents, but is actually executable when you finish writing the code to make it work.

The key to all of this is realizing that design happens at a number of different levels. In the examples above, I described design the level of writing code (DSL), of integrating with systems (API), of browser interaction (routing), and of user interface (web page).

I think that more and more people are realizing the power of this approach at various levels, but I’m convinced that recognizing each of those levels as an instance of using design-first development may provide better insights into the process overall.

Say I was selling a Twitter client on the App Store. In an ideal world (read: the web), the primary bottleneck to delivering a new version of the product is the development time – Twitter releases lists, I burn the midnight oil a bit to incorporate them into my app, and I’m done.

When you’re developing for the iPhone, however, the main bottleneck isn’t the development time, but the approval process. Every update to the core functionality of the application has go through the approval queue just like a new application, which means that it can be weeks or months before it gets onto your customers’ phones. (Or never, as has been the case with a recently rejected app update.)

Similarly, entirely new applications face the same problem. Fred Wilson just posted a Twitter list-powered application idea, but there’s no way a native app could be released to the public quickly to take advantage of it.

This has always been something of a problem for desktop development, of course – particularly before online patch distribution – but the iPhone has taken it to new heights. Web clients were able to add support for lists as quickly as they could push their developers, but native applications are left to lose their audience until Apple deigns to approve their updates. I’m surprised that the effect isn’t greater, actually, since the web-based Twitter clients should be promoting the heck out of mobile-optimized views of their sites with list functionality. Scoble‘s favored way of interacting with Twitter is a web-based client, in part because of its list support (see the last paragraph).

This is just one more problem with the App Store approval process, but it has the potential to be one of the most serious. As more and more mobile applications rely on web services for their functionality, the mismatch in time-to-market between the moderated App Store market and the quick-as-you-can web ecosystem will cause more (and more serious) problems.