Three months ago I wrote an article about going from agile development to something that would speed up development at the expense of quality. It isn't meant to be a scientific transition. It is meant to simply drop some of the good and sound practices in order to increase development speed at the expense of quality which, ironically and conflictingly, introduces both: increased business risk and a chance to succeed because you give yourself more of a chance to innovate.
In any case, any technique under discussion is just that -- mere theory. In order to prove or disprove the theory by practice, I applied the suggestions I used on a group hiking site that I launched a short time ago. I can now share my findings on a few of the core topics which I had mentioned in my original article and put into practice while developing this site. I can now comment on where I was wrong and where I was right in my theoretical assumptions from 3 months ago which had been tested by practice.
1) Technology is Commoditized
It is no secret that projects which used to cost a million dollars to develop ten years ago, can today cost under fifty thousand dollars, and in many cases much less. That really isn't theory. I was able to design and develop features very rapidly, enabling me to spend about 50% of the total time I had spent working on the site on engineering tasks, and more time and effort on promoting the site. Whenever I was stumped I found nearly perfect solutions through Google, and quickly learned about many aspects of building a site which I had no previous experience with. Searching Google for tech solutions is nothing new, but the speed with which I could get myself up to speed on topics I had no previous experience with has improved many-fold since even 2005. New developer community sites like StackOverflow really help to get even tough questions answered fast.
2) Technology Risk vs. Market Risk
Even before embarking on the hiking site, I rapidly prototyped a few different projects and put them out in the market as very-alpha products. Few of those early products got so little interest that I knew not to pursue them, and I was able to quickly drop a few of those projects immediately.
The hiking site got positive feedback from enough people that it made sense to develop further. Plus, I liked it because out of the many site ideas, this one clearly aims to do some social good which was important to me personally.
Once I got started prototyping and developing features for the now-vetted hiking, I knew that no matter how many omissions or coding pitfalls I fell into, building the site in PHP gave me a fighting chance to fix what I will have needed to fix in the future. PHP is a mature and proven language and I knew that when it will be time to add care and quality to the code, PHP will enable that for me. That lets me assume that there is very little technology risk associated with creating a PHP site.
What I didn't know was whether any of the features I was making were going to be compelling to the general public, and whether there would ever come a time when I needed to improve some of my prototyped features.
As things stand now, the site is getting a little bit of adoption, and I am having to go back and edit (not totally rewrite yet) some of the code to be more secure, user friendly and polished. But many of the features I had originally thought were going to be useful, were not, and I am glad I didn't spend too much time on them which also makes it psychologically easier to make the decision to throw away what is not needed.
3) Being a Technical Debt Millionaire
While there is something catchy about this headline, I don't advocate deliberate accumulation of technical debt. Unfortunately, in properly run start-ups it is probably inevitable because as the old saying goes, if you are not embarrassed of your initial product at least a little bit, you've released too late.
Start-ups have to release early and release often. They have to constantly make improvements and adjustments based on various sources of feedback and a molding product vision. This type of rapid release cycle naturally introduces many technical oversights, resulting in an accumulation of large technical debt over time.
4) Security Only After Being Hacked
This suggestion is obviously "out there" but ensuring that a site is fully secure can be a full time and expensive job. It wasn't my first priority and my site did get hacked through some basic SQL injection. Google Analytics was able to show the exact string that succeeded in hacking the site and that gave me a great practical example of what I should protect the site against, and I did. That and adding captchas, obsessive parameter validation, and an internal alert system that sends me email when something suspicious goes on, has prevented any foul play on the site so far. There are a few more unsecured points that need to be addressed moving forward, but I won’t make those security flaws public until I protect against them.
5) Forget Scalability
So far, I have gotten away with not worrying about scalability for a bad reason: the site has not had any significant spike in use. So probably focusing on getting to the point where scale actually happens is more of a priority at such an early stage. The only thing that warrants scalability work in the early stages is putting a big effort into sound design of data structures and the database. No one can predict with exact accuracy what the site will require in the future, but sound practices always seem to help steer the architecture in the right direction.