Archive for June, 2009

Sunday, June 21st, 2009

The BIG fuss about Agile Developments

I recently attended a session by Mr Joichi Ito on the topic of “Consumer Web in Focus” , and those who are lucky enough to get selected to pitch should know exactly why I haven’t stop praising the man since with the one-on-one session on FAME. I tweeted immediately on the most important takeaways on that day; #1 Develop a Scientific Approach (A/B) for Testing #2 Establish that WOW factor in the first 5 mins #3 Ensure Survivability in our game for all players.

In the talk itself, Joi spoke about the different stacks in the Internet, different tiers of VCs and how good products do not necessitate good a strong traction. The best lesson of the day imo to most aspiring entrepreneurs is on how startups should really “just do it” because it may cost more to find out if a product is really feasible than to work on the actual application suite itself. And to do that, your development methodology has to be agile and iterative.

Meet Extreme Programming (XP), one of the Agile methods Joi spoke about. The most “notorious” rule in XP is the arguably the concept of Pair programming. Most of my peers swear by the inefficiency, but they also tend to overlook some core benefits. Having multiple pair of eyes on the same screen in theory can produce better codes and applications in the long run. The programmer becomes disciplined while getting the occasional slap-on-the-wrist from his comrade. The comrade provides a second opinion on the functionalities, style and refactoring method that the programmer coded. The end result is both of them learns from each other and one can be sure pretty sure that the codes do what the client requires because 2 heads think better than 1. Still, time is an expensive commodity in the IT industry, and people gets edgey over such perceived redundancy. I would suggest that pair programming can evolve into 2 developers sitting alongside each other with their own macs, constantly checking on each other’s progress and using Subversion to sync their codes. (I will talk about SVN in another post) - lots of communications take place verbally to ensure the requirements are “what they are”.

The most important rule of Agile Development is probably the iterative nature where you can expect many many releases. Again, having multiple releases (not of the whole damn suite, but instead of individual components) again reaffirms the product development guy’s vision, as well as allowing the marketing person to track with his focus group. Any cost in changes is limited to between T=0 and T=1, where 0 marks the start of development and 1 marks the first release. At the end of the day, it’s about coding that “thing” quickly (e.g. with ROR) and roll it out to the market quickly in anticipation of Change Management. In Joi’s view, this makes much more sense than trying to figure out if your product works. Doing it on the cheap is feasible compared to 10,20 years ago (think waterfall approach, gasp*)

I would like to take the liberty to suggest an extension; Invest in refactoring your codes and deploying elegant framework (MVC is a nice pattern). While Joi is right about developing a product quickly to feel the market pulse, that does not mean you prioritize speed over scalability and elegance. I propose the 40/30/20/10 rule; Spend 40% of your development efforts coding, 30% testing, 20% refactoring, and 10% documenting and making sure others understand whats going on. The Web is an amazing paradise to launch products, only if one can scale and adjust at god speed.