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.