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.