I recently read a post by Alissa Heywood subtitled - "Don’t worry about catering to everyone" . It was a quick read, but what hit me the most about it was the fact that Alissa had gone through the lifecycle of maintaining products all by herself on Github. A lifecycle very similar to one most products and apps built by companies go through. There are striking parallels in what Alissa went through and what startups that end up making it, go through. Good intentions, a couple of clients and the desire to say yes to all requests lead to the same feeling of "shadows looming over" in corporations that Alissa felt.
Let us draw the parallels - A startup development team has a product it believes in. The owners hit the road and sell hard and find a couple of clients that decide to take chance on the upstarts. There is elation, we have people using our software, it will only get better from here. Development team loves the fact that they were able to work together to create something new and shiny that is being used and keep developing new features with enthusiasm. The psyche of the company begins to change though. We have to keep the clients, we "MUST help" our clients. We are not able to say "No" to the customers for new feature requests and especially to bug fix requests.
Initially, the team is able to keep up and puts in the extra hours to fix the issues, while keeping on working on the new features. Things do tend to change further though. Something similar to what Alissa recorded happens - "...I had numerous problems adding up. I then started just closing issues, telling users to fix it themselves and leaving the issue to rot. This worked until I started gaining issues. The guilt sunk in as the issues unsolved grew into the double digits. And I just left them there to rot.". Replace "I" with "we" and you will see the familiar story of development team that is having a hard time saying no.
Morale starts to flag. Developers start complaining about the fact that they are doing maintenance work instead of actually solving new business problems. The problem feeds itself as the multiple patches put in often results in even more issues propping up. People start to burn out working overtime to keep the product afloat. Being a programmer or a developer over time loses its meaning as the entire team spends most of its time on maintenance tasks and bug fixes. The hallways start having the refrain of "Things are not how they used to be" echo through them.
Finally we get to the point where the company hits reboot. After many days of trying "face the guilt of people expecting me to dedicate time to their specific issues", the company tries to delete history and move on. It hires some people for maintenance of the old product if it has the money or just shuts down support for it. In some cases, even massive refactoring projects to make the code base maintainable and more modular. Either way, it tries to give the jaded developers what they have wanted for a while - the ability and option to do development activities other than bug fixes and maintenance work.
Alissa sums up the moral of the story really well and it applies at the macro (development organization) level as well - "You will feel guilty at first, but you should realize that trying to cater to everyone is never optimal". Remember that the real power is in saying "No". It will save your developers a lot of heartache and will maintain the startup buzz and culture that helped build great products in the first place.
No comments:
Post a Comment