From:
http://mark-lucovsky.blogspot.com/2005/02/****pping-software.html
"I am not sure I believe anymore, that Microsoft "knows how to ****p
software". When a Microsoft engineer fixes a minor defect, makes
something faster or better, makes an API more functional and complete,
how do they "****p" 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
"****p" 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 cor****ations, they
won't see the software for a year or more post RTM...
"Consider the .NET framework for a second. Suppose you wrote something
innocent like a screen saver, written in C# based on the .NET
framework. How would you as an ISV "****p your software"? You can't.
Not unless you sign up to ****p Microsoft's software as well. You see,
the .NET Framework isn't widely deployed. It is present on a small
fraction of machines in the world. Microsoft built the software,
tested it, released it to manufacturing. They "****pped it", but it
will take years for it to be deployed widely enough for you, the ISV
to be able to take advantage of it. If you want to use .NET, you need
to ****p Microsoft's software for them. Isn't this an odd state of
affairs? Microsoft is supposed to be the one that "knows how to ****p
software", but you are the one doing all the heavy lifting. You are
the one that has to ****p their software the last mile, install it on
end user machines, ensure their machines still work after you perform
this platform level surgery.
"When an Amazon engineer fixes a minor defect, makes something faster
or better, makes an API more functional and complete, how do they
"****p" 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 ****pped to them, and they didn't have to lift a
finger. Now that's what I call ****pping software.
"I would argue that Microsoft used to know how to ****p software, but
the world has changed... The companies that "know how to ****p
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."
|
