Saturday, July 30, 2005

Its not just about the Code

The title & article is inspired by Lance Armstrong's book "Its not about the bike" where he recounts his experience of battling with cancer, recovering and going on to win the worlds most gruelling physical event - "Tour de France". In this book he talks about all what makes a winner (besides the bike). A recommended read.

Last saturday, I happened to get visited by an ex-employee of Mithi who used to be a developer on my team. I was asking him about their development processes, systems and tools since they were serving international fortune X clients with their product. In the course of our discussion I discovered how much 'code' focussed their team was. They didnt have any formal processes to track issues, resolve issues, perform reviews, test case documentation, feed the documentation team, perform releases, automated testing, etc. The whole system was working on 'heroics' with ad hoc processes and arbitrary checkins. The QA team also always started from scratch without any documented test cases & reported issues via email. If an employee left, he left behind a legacy of unmaintainable code. Basically kind of chaotic. Of course they have managed to get some order from the chaos by "systemizing the chaos/arbitrariness".

But it got me thinking. I analysed that their user base is very small (their niche product is sold to a few large corporates where a few users will use the product, totalling maybe 30-40 users), hence they are dealing with a small end user world. Its possible for them to get away with their current way of working and even handle error/bug reports from these customers one-to-one. But when your product starts to reach out to larger number of customers and is used by an even larger number of end users, then the need for a formallised process and system kicks in.

Without a formal issue tracking information system, templates for design/fixing bugs/closing issues, a process for review, a process for documenting test cases for regression, an automated testing system, a source control system, a release engineering team, a formal release process... one is asking for serious trouble in the quality area. Even if the code is perfect, the process and systems around it can break the whole delivery and support of the product. If the inflow of issues from the customers is high, the whole team can get locked into support, letting the future growth of the product languish.

In my future blogs I would like to share with you how we handled rapid growth in customers and users. I will share how we put some of these systems in place, at a very low cost to up our efficiency, consistency and reliability. Putting in systems/processes also reduces dependance on human resources, so the company is better equipped to handle attrition.

BTW, the latest news from my ex-employees company is that their latest release wasnt taken too well by their customers. So much for a systemised chaotic system breaking down.

Monday, July 25, 2005

Programmer maturity

On a Saturday afternoon, I & Aditi (my colleague and co-founder at Mithi) were interviewing a candidate for the post of a software developer, and I as a matter of routine asked him (this is after a tech evaluation, which he had cleared), how long he plans to stay in Mithi. He was prompt in his reply - '6 months'. I was quite taken aback by his ‘clear’ thinking (considering that he was fresh out of college). When I mentioned that it takes around 3 months before a fresh join is productive (to be really useful), he very casually said that ‘OK then I will stay until 9 months to do justice to the job’. Such people are very clear that in small and startup companies, they will learn the most and very fast. They believe that such small companies should be used as a stepping-stone to their personal growth. Amazing, this clarity of thought….

I feel that very large organizations are primarily process and system driven, to the point that any body (satisfying basic criteria of intelligence, academic qualifications, aptitude) can come in produce almost immediately and be of value. These people basically run the system/process (created by others), part of which is monitoring and reporting to ensure that these guys are doing a good job. The system ensures that they produce. Such organizations can recruit in large numbers, get work done, and it doesn’t affect them too much if there is a regular and heavy turnover. In fact many such organizations have perfected the art of selection, recruitment, induction, and exit. (Infosys recently had 730 people join on a single day…to get so many people through the security itself is evidence of how process driven the organization is.)

Unfortunately for small companies & startups, who have to first struggle to find the right product, strategy and business model before putting corresponding processes/systems in place, they need to find people who will go through this struggle and set the system/processes, which will be ‘run’ during the growth phase by the type of people described in the previous paragraph. In such an environment, a heavy turnover causes slowdown in the companies progress and can push the start of the growth trajectory. For such companies the primary selection criteria could be people with the right attitude & character, having desire to create something of lasting value, risk taking ability, have deep belief and confidence in their own abilities and possess a natural drive. Such people know that even in the worst-case scenario of the company failing, they will be only be better off personally.

I have to admit that such people are rare…No wonder that only 1 out of 100 guys make through our (Mithi’s) selection process. BTW, we took a tough call and let the 9-month guy go.

The pain and gain of running a business.

I've been following the Tour de France closely for several years now and have watched how Lance Armstrong has improved year after year to win the worlds most demanding race 7 times in a row. At age 33 he is peaking as an athlete. One would think that a younger, stronger, energetic and more aggressive athlete would have bettered him. And there were many in the race and several of them even won individual stages (battles) but the war was won by the wholistic athlete. Its the cumulative learning from successes & failures, controlled aggression, sustained exposure to competition, and team work (read trust in others) that are required beyond physical strength, genetic ability, and a deep desire to achieve. Thus it has been observed that athletes peak in their early thirties.

If you equate business to athletics, and assuming that you have the desire, drive and enthusiasm (hard core entrepreneur) to create a long lasting business which has solid potential for growth, you need to put the business (and yourself + your team) through the rigors of 'training' - viz. conceptualizing, prototyping, early exposure to customers, quick & sharp product releases, taking risks, patience, perseverance, personal growth and adaptation (and repeat it all over and over again) to get all the ingredients (strategy, biz model, product - ver 3, systems/processes, partnerships) in the right mix for success (defined as ‘making money’). I relate to this from our experience of setting up Mithi. It’s been a long, tiring, treacherous but exhilarating climb through the Alps. But every minute of the race has been worth it. Given the breathlessness, pain and discomfort of growing a business from scratch, the journey is one I wouldn’t swap for anything in the world. It’s made each of us at Mithi a better person. We just need more Lance Armstrong’s (read hard core entrepreneurs) to setup businesses and create vast opportunities. BTW, my personal belief is that businessmen peak in their late thirties. (Hey! There are going to exceptions).