“Agile” software development states you should try and get software out in front of people as soon as possible. Specifications are just documents, software is real - and you can’t get feedback, see what works or improve until what you have is out in the real world. 37Signals, creators of Ruby on Rails and Basecamp, call this the “Race to Running Software“. They even went as far as to launch Basecamp with no billing capabilities - using the 30-day period post-launch to add it in time for invoice day.

For the most part, I agree. Specifications are a dream, not reality. Paying customers pinpoint the important issues much more accurately than the development team. Working in small iterations means you always know where you are.

But it does have its downside - as experienced by the Northcrew at the moment. For as soon as you launch, you become public property. And if you are a success, as Northpack undoubtedly is, the public immediately wants a piece of you. “What are your plans?“, “Why doesn’t X do Y?“, “What about ownership issues?“, “What’s in it for me?” - all get thrown at you. And, having concentrated solely on getting something out of the door, this barrage must feel pretty overwhelming. Especially when it’s something done in your spare time, that costs you money and is given away for free (in Northpack’s case).

To be honest, I’m not sure what the answer is - you have to focus on the next stage, otherwise you don’t have a product. But you need to be prepared for three or four stages ahead or the barrage will drag you down. This becomes even more important if this is a commercial service - if you are taking people’s money they need to know what they will be getting for it. However, I’m not sure how divide your time between the very real needs of now and the potential needs of the future. Any ideas?

“Cyclists Racing” by sritenou.