There was this blog post years back about the number of Microsoft employees it takes to make simple changes to its products’ source code.
… how many Microsoft employees does it actually take to change a lightbulb?
One dev to spend five minutes implementing ChangeLightBulbWindowHandleEx.
One program manager to write the specification.
One localization expert to review the specification for localizability issues.
One usability expert to review the specification for accessibility and usability issues.
At least one dev, tester and PM to brainstorm security vulnerabilities.
One PM to add the security model to the specification.
One tester to write the test plan.
One test lead to update the test schedule.
One tester to write the test cases and add them to the nightly automation.
Three or four testers to participate in an ad hoc bug bash.
One technical writer to write the documentation.
One technical reviewer to proofread the documentation.
One copy editor to proofread the documentation.
One documentation manager to integrate the new documentation into the existing body of text, update tables of contents, indexes, etc.
Twenty-five translators to translate the documentation and error messages into all the languages supported by Windows.The managers for the translators live in Ireland (European languages) and Japan (Asian languages), which are both severely time-shifted from Redmond, so dealing with them can be a fairly complex logistical problem.
A team of senior managers to coordinate all these people, write the cheques, and justify the costs to their Vice President.
When I read that article, I was just a few months old in the industry, and at that stage it was comical. I was in a company where customer-requested changes were incorporated soon and customized code was written and a separate build was released. I found it amusing then, that a company like Microsoft was so slow in responding to changes and that the company I worked for was much better in that regard.
Those were the golden days of being a fresher in a small product company. When I joined, the product was just picking up in popularity and sales, so it was exciting times if one was in Engineering.
I didn’t realize then, that:
1. Microsoft catered to millions of customers and users, while my company had, well, 300 customers worldwide.
2. Changes handled by Microsoft would have far reaching consequences into other programs, while changes in my company’s software could at max crash itself.
3. We didn’t have much of a process related to security, localization, documentation etc. Maybe there was, but not much importance was given as would be in Microsoft.
After these few years in Product Management, I can empathize better with Microsoft. When you are building a product that touches millions, you better have strict quality control in place; but not so much that the whole process inhibits progress. In such products, its better to be cautious and right than being fast and wrong.
Of course, its easier said than done. My current product has only a handful of customers. It’s a B2B Product and each customer is worth a sales of atleast $2Million. So naturally, it means that we will bend backward(and forward) to make any changes a customer requests AND we will also take it through a change request process. So it’s a challenge while implementing customizations, bcos the customer wants it yesterday, the Engg team has completed the changes today and the approval committee is discussing about it tomorrow. I normally grow a beard during such days and people tell me that my socks colors are different.
Life can be better. Rather life SHOULD be better than this. but how? Need to step back a little and think.