Mark Lucovsky (formerly with Microsoft and now with Google) writes:
I am not sure I believe anymore, that Microsoft “knows how to ship software”. When a Microsoft engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they “ship” that software to me? I know the answer and so do you… The software sits in a source code control system for a minimum of two years (significantly longer for some of the early Longhorn code). At some point, the product that the fix is a part of will “ship” meaning that CD’s will be pressed and delivered to customers and OEM’s. In best case scenarios, the software will reach end users a few months after the Release To Manufacturing (RTM) date. In many cases, particularly for users working in large corporations, they won’t see the software for a year or more post RTM…
When an Amazon engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they “ship” that software to me? What is the lag time between the engineer completing the work, and the software reaching its intended customers? A good friend of mine investigated a performance problem one morning, he saw an obvious defect and fixed it. His code was trivial, it was tested during the day, and rolled out that evening. By the next morning millions of users had benefited from his work. Not a single customer had to download a bag of bits, answer any silly questions, prove that they are not software thieves, reboot their computers, etc. The software was shipped to them, and they didn’t have to lift a finger. Now that’s what I call shipping software.
I would argue that Microsoft used to know how to ship software, but the world has changed… The companies that “know how to ship software” are the ones to watch. They have embraced the network, deeply understand the concept of “software as a service”, and know how to deliver incredible value to their customers efficiently and quickly.