Sometimes Programming Is Like Building Your Car While Driving Down the RoadJuly 23, 2012
Our executive team decided we needed to jump into a related new market and build a new iPhone app in essentially 2 weeks. So we jumped right in with both feet and 3.5 folks and two product people.
Needless to say that was impossible and I am sure we all knew it.
Weeks later we are still working on the app with constant changes that are making development a bit like Mr Toad's Wild Ride. Crazy is an understatement. Sometimes we can't even code a new idea before it becomes a bad idea. Things are coded quickly to enable testing to determine if the idea is even worth coding!
Is it a flaw in our company, bad management, a lack of planning, poor methodology or incompetence? Actually, I don't think any of these are correct. It's the nature of our competition, our industry and the highly dynamic needs of our customers. I think a lot of startups probably feel the same sometimes, there is only so much money and time and something has to be out of door soon or it's all over. When you get into that situation all the normal nice software development best practices and methodologies get left in the dust.
Of course it's risky to write code without knowing exactly what the code is supposed to do. Refactoring is a good thing but doing it to the same code over and over again is hard work. Eventually ideas that were changing hourly start to solidify while others remain a moving target. This makes designing and testing code beyond challenging. It requires flexible thinking, creative design and a willingness to trash days of work if necessary.
One of my favorite shows on Cable is Chopped! from the Food Network, which chefs are given a mystery basket of ingredients and little time to prepare something. Having watched it for years it's amazing how time pressure and strange requirements make even experienced chefs produce inedible crap. Yet people can still manage to make great food as well. The additional problem we have is that the basket keeps changing.
Most people probably don't have to work on a project this dynamic but I am sure in competitive industries it isn't unheard of. Software is theoretically infinitely malleable but there is a serious risk if you do it too fast. Yet the cost of having a product be first rate but appear last in the market may be even greater.
An interesting side note is that we are being "introduced" to using Kanban to manage the project, which appears to be completely mismatched to something this dynamic. Nothing we have ever gets out of "in progress" or "future" since no story is ever finished. The rest of the company operates at a much slower pace using Agile/Scrum but even that wouldn't work here as we would have to have a sprint of about 2 hours which is pretty laughable. I don't know of any methodology that would work here. Electroshock therapy maybe.
In a perfect world there would be enough time and people to plan, test, design, understand the market, and all the other things that a normal idea for a product would entail but reality isn't always so neatly controllable. Your competitors big and slow and small and nimble are all trying to get ahead of you and everyone is in a similar boat. Bigger competitors can outspend you and little startups have no baggage so they can get there first.
I've been there before with long and organized and short and crazy so it's not totally alien to me but I am sure a lot of people would be freaked out by designing code while writing code while changing requirements but still meetings lots of temporary deadlines (user testing, executive demos, etc). Even with all this dynamism the end result is becoming clearer but we still have to deliver a functional, usable, quality product or the whole process was pointless.
Despite all the stress the only thing that really scares me is success. If we can develop a good product in this crazy fashion and short timeframe this time, we might be expected to do it this way every time!