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.

Ultra Lean Development Pro: Database Was Easy to Fix

Ideally for me, the data in my MySQL database would have been stored in utf-8 character encoding, and the storage engine would have been InnoDB. If you are wondering what your database storage engine and character encoding are, here are the MySQL commands to check that.

This checks the storage engine that you are using:

select table_name,engine from information_schema.tables where table_schema = 'your_database';

This checks the character encoding of your data in each database table:

select c.character_set_name from information_schema.tables as t, 
information_schema.collation_character_set_applicability as c
where c.collation_name = t.table_collation and t.table_schema = "your_db";

If you need to change db formats, here is how to do that:

This is how you change a table character encoding to utf-8 if that is what you want:

ALTER TABLE tableNameCONVERT TO CHARACTER SET UTF8;

And this is how you change the storage engine:

ALTER TABLE tbl_name ENGINE = InnoDB;

That should get take care of your data formats and how your database is storing it.

Ultra Lean Development Con and Pro(?): Buggy Features

As you might have guessed, in having a live feature less than a day before it was even conceptualized, does not give a lot of time for testing. Unfortunately, my poor users had to catch all the bugs which I did not notice during my own testing. Admittedly and obviously this is a real con and I regret that because many of these people have likely left forever, and are disappointed with the site.

Fortunately, I was able to send myself email alerts whenever the application caught errors. That allowed me to take something negative on the site, and turn it into a positive by sending myself alerts when the errors occurred. Once I got the alerts, I was able to send a support email to the person who encountered the problem while they were still on the site, and often even that same page where the error happened.

When I emailed people asking them if there was some way I could help them with the site, they were often quite forthcoming and appreciative of my alertness and responsiveness. Many such users who first encountered bugs got excited about finding more bugs, and feeling like they were part of something. Many of them became super users and evangelists of the site, recommending it to their friends.

Other Gotchas and Unforeseen Nuances

With the choice of speed over quality, it goes without mentioning that I ended up with lots of poorly written code and half-baked database tables. Fortunately, much of the code and the database work were mere experiments to see whether users liked or disliked whatever I was making.

Ultimately the architectural oversights were not as harmful to the project as they could have been. I didn’t completely escape without scars though. There are some pages which were originally done in a quick and dirty manner, but have since been iterated over and improved well over 10 times. But who knows, that might just be natural since those pages became incrementally better over time.

Another unforeseen problem was that since I was able to create new features so fast, the time investment, and therefore risk of heading in the wrong direction became dangerously small. After all, I could just throw that page or code away. But it ended up backfiring as I let too many features creep into the project and they are ultimately never as easy to simply throw away as it might seem. Each feature requires consideration and difficult decisions to be made about the direction of the overall product.

Still to Be Determined

It is still too early to make definitive conclusions on what is happening with aspects of the architecture that deal with actual business objects and the database meta-data. Most of the business objects are still being molded and reshaped with the rapidly changing business requirements that come with a start-up environment.

Would I do things this way again?

Many of the mistakes came from lack of experience. I was just one person responsible for every piece of the engineering puzzle from the database to the UI and UX. I was also responsible for the business side of things. I made plenty of mistakes in both due to insufficient experience in every single skill that a company may need.

If I was doing it all from scratch again, I would obviously start with a more correct database setup. I would also likely work with a UI designer from an earlier stage of the project. I’d also put more of an emphasis on building less features with higher quality, but that is more of a product issue rather than a purely engineering issue. In fact, it is a catch-22 since the original premise was to use a more risky engineering approach in order to be able to put out more features in a shorter amount of time in the first place.

Getting back to the original premise that the ultra lean software development approach will be better for this type of a company, I would have to say that if you have a disadvantaged project in terms of people, money, and time that it has before it can succeed, this is definitely a viable option. After all, the ComeHike site does not have any huge fires or bugs that can’t be solved. And by releasing many features rapidly, there is also a lot of learning that goes on in every facet of the business like monetization, marketing, the general likes and dislikes of the target demographic, etc.

So the short answer is yes, I would do this again, with a little bit less of the “ultra” and a more experienced eye for long-term engineering and business design.