Approximately nine months ago I wrote an article outlining something I considered to be "Ultra Lean Software Development" and give it a real world test on a new hiking start-up I was just starting called ComeHike.com. Then it was called HikingSanFrancisco and had a much narrower focus than it does today.
The idea behind the ultra lean software development concept was to take the lean start-up movement's continuous and rapid deployment techniques which are aimed at enabling rapid product iteration, and speed them up even more, essentially kicking the gas pedal to the floor. The approach entails dropping some or many of what are traditionally called "good practices" in exchange for an increase in the speed of bringing features to market and in front of real users.
That might seem reckless, and in many ways it is absolutely reckless. This approach is only appropriate for a very small percentage of projects. My project at the time had seemed like a good fit because it was a little company of one person who was me. In a single day I had to code, do marketing, do customer development, product design, market research, and make time to sleep or eat.
My goal was to be putting the product in front of people as soon as I could, and continuously get feedback in order to make continuous improvements. I had no choice but to speed up development as much as I could, especially since this project was not funded by anyone and I did not foresee any funds coming into it other than the revenue it would make on its own.
Now, nine months after the project started as HikingSanFrancisco, I can share what went right and what went wrong with what is now ComeHike.
Ultra Lean Development Pro: Big Gain In Speed Was Real
This technique really worked in speeding up my coding. Working mostly on my own and only able to focus on coding part of my time, I was still able to build things pretty fast and show few features to customers on a near-daily basis. Sometimes I'd think something up in the morning, actually code up that feature by the afternoon, start marketing it right away, gather feedback, make appropriate fixes, and by evening already be releasing version 2.0 of that feature.
This wasn't a typical day, but it wasn't uncommon either. So I'd consider my main goal of increasing development speed accomplished. But the increase in development speed wasn't without drawbacks, some of which I'll discuss in this article and share what I think may be better approaches or solutions.
Ultra Lean Development Con: Bad Design, Uncoordinated UX and Product Vision Drove Away Users
While some of the biggest problems happened on the database or back-end architecture, the single biggest shortcoming was the design, UX and the look and feel of the overall site.
Many of the features I was bringing live were not polished with design and therefore were turning many people away from the site who would have otherwise likely used them.
Lesson learned: Design is very important in a user-facing application. There is a long-standing debate in the Web world whether design is crucial to the success of a site. People point out Craigslist as a case where design does not have to be great. Borrowing from that argument, I thought I could get by on just "ok" design, but it seems I was quite wrong about that. Design is still the #1 complaint users have about the site.
Ultra Lean Development Con 2: Database Settings and Other Problems Behind the Scenes
When thinking about back-end architecture, many people are quick to point out topics like scalability or load-balancing. Despite having hundreds of people on the site daily, such topics never came up for me.
What was more of an issue was that the many users all used the site slightly differently, which resulted in them breaking the site a little bit in their own way. Through debugging the different errors on the site, I learned that the database had been configured with incorrect initial defaults which was beginning to cause problems with user-entered data.