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.?

[login]

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.

6) Saying No To Good Ideas

Over the short time of working on the site, I have already talked to many people who have made great suggestions about what I should do with the site.? I try my best to create all the features people suggest and request, but there is always a balance of improving current features vs. making the existing features more stable.? Plus, if I really did everything people asked for, I’d have a feature list a mile long that would take too long to complete, and eat up too many of my already too-few resources.? Not to mention that many site features like privacy are conflicting.? For example, generally, web projects thrive when they are free and open (think Twitter or Open Source community).? At the same time, people need their privacy which necessitates at least some degree of restriction (Think early Facebook appeal, or strict control imposed by Apple).? The balance is difficult and it is impossible to please everyone.

7) No Heavy Languages

In an earlier article I made the point that Java was a language that is becoming less popular and that other, newer languages are gaining more and more traction. Many Devx readers pointed out the many tools that make Java competitive and still superior to the newer languages.? I probably over-assumed in my original assessment.? My question to the DevX community is: With Oracle now owning Java, what is the future of the language?? And is it risky to start new code bases on Java because of the uncertainty of where Oracle will take this language in the future?

8) User Experience Over User Interface

I think I got things all wrong on this one as I over-simplified what goes into the overall look, feel and navigation of the product.? There isn’t just the balance of a site being pretty vs. high level of usability.? Here are just some of the many factors a modern site has to take into consideration:

* Navigation clarity and usability (UX).
* Nice, pleasant and professional design.
* SEO friendliness.
* Copy that is written for humans instead of search engines, but helps with SEO as well.
* Conversion (ad clicks, user sign-ups, product sales, user retention, engagement)

Most sites do not get all of these aspects balanced well.? In my site’s case, I focused too much on the SEO side, and am catching up on the design, navigation and clarity side.

9) Real Gain From Prototyping

So in the end, what was my gain from the rapid prototyping?? The short answer is that a feature release can take as little as 4 hours from concept to live realease.? Consider this in light of how a mid-size company would go about releasing features.? First, there would be market research and meetings.? Then a product plan would be created.? Then the necessary features would be given to the design team and the engineering team.? The engineering team would operate on about a weekly release schedule.?

In total, the mid-size company product release cycle from concept to product release would be considered good if it took under 3 or 4 weeks.? In a large company,it may be as long as 3-6 months.? In my case, in one instance, I was chatting with a site over email and before my exchange with him ended, I was able to point him to the live feature that he wanted, which was already on the site.? I used breaks in our conversation to code the feature and quickly released it to pleasantly surprise him.

Needless to say, the person asking for the feature was quite impressed. My only caveat was that I had to warn him that I had just made this feature as I was talking to him so it may be a bit buggy initially.

10) Reader Experiences

What are some of your experiences developing new sites?? Did you take some of my approaches?? Did they work for you?? Did you do something else that worked better?? Email me and let me know.