Microsoft realized that phishing, pharming, botnets and rootkits show that attacks are becoming more sophisticated. This situation makes traditional defenses to be inadequate and evolution is at hand. The Redmond giant has been mentioned in a positive context many times during the past year for the advances made in the security arena. At the Infosecurity Europe 2006 Press Conference, Detlef Eckert – Microsoft Chieft Security Advisor EMEA – demonstrated what Microsoft did and what more we can expect in the near future.
That has been a large concern for some of us.
I would personally much prefer a stream of single-issue microfixes to a single monolithic bundle of them once a month, since fix bundling tends to lead an an “all or nothing” situation.
You have to understand how long developing a fix takes. It has to be examined, fixed (and try to make sure it doesn’t break something else), tested throughoughly, and finally deployed. If they put out fixes quicker, they risk bad patches that break things.
Now, putting patches out as soon as their ready would not only be more work for MS, it would probably also piss off users. More updating, more reboots.
Of course, for critical stuff like WMF, they will push it out faster though.
Have you ever worked for a large software company? Things are much easier said than done.
Being a large software company is not a valid excuse. Your argument about what needs to be done is very true, testing takes a lot of time (although not more than a few days if they’re smart), but the size of the company is not a valid excuse for why it takes time.
If a small company can do a better job than we should all just avoid products from big companies! And I don’t think Microsoft suffers from IBM level bureaucracy.
Why is it not a valid excuse? It’s a valid excuse for why it may take longer than for a small company. But that also has to do with customer base and product size.
There is a lot that a patch has to go through before it can be safely deployed. It’s really hard to describe why, but when you work for a software company, you understand better.
A well-designed application can be effectively QA’d and released quickly regardless of the size of the customer base. You just need a decent QA process in place (those can be relatively fast as well — see various articles on the topic of “Agile Software Development” about how such things can be done quickly while avoiding many of the speed issues found in traditional Waterfall methodologies), and perhaps one or two verification sites to ensure that the stuff which was working on the test and QA environments will also work in a few live production environments.
Things like language support should be a nonissue as long as the product is well-designed. We have always kept our text messages (which are multilingual) separate from the code program logic, making it easy to test the core and then plop in whichever language and other localization files are required for a given variant.
It’s all process-centric, really. If a company has a poor process in place, its capability for fast action is going to suck regardless of its size.
You have to understand how long developing a fix takes. It has to be examined, fixed (and try to make sure it doesn’t break something else), tested throughoughly, and finally deployed. If they put out fixes quicker, they risk bad patches that break things.
With all due respect, I think I have a pretty good idea of the time and process involved. My resume is on my web site — feel free to snoop around.
Besides, I wasn’t talking about speeding up the process for each fix so much as converting from a regular monthly release cycle of monolithic fixes (conglomerates which include several fixes, or perhaps dozens) and instead releasing each fix to interested customers as it becomes ready for external publication. Make it a premium support service if you have to.
Both IBM and Unisys release patches that way for some of their products, including their mainframe OSes and other key software elements. Why can’t Microsoft do the same? Surely they’re capable of doing so.
I realize (from reading various blogs and such) that Microsoft’s culture appears overly process-heavy when compared to other similar companies. That might make it more difficult, but as a customer I’m not sure I want to hear about their organizational or procedural difficulties if I can see other large organizations doing things more efficiently.
Have you ever worked for a large software company? Things are much easier said than done.
Yes. I spent almost five years working for a large mainframe software company (half of that time in a software development group releasing software for external customer consumption), and then I spent ten years doing internal s/w application development and support for a major airline. I’m doing similar work now, albeit for an airline communications/software firm instead of an airline directly.
I’m acutely aware of the types of procedural inertia that are in place in large organizations, and I’ve also seen it broken through when enough key people bought into a change.
There are times when inertia is *NOT* a valid excuse.
You have to understand how long developing a fix takes. It has to be examined, fixed (and try to make sure it doesn’t break something else), tested throughoughly, and finally deployed.
No I don’t have to understand. As a customer it’s not my business to think how hard is for them to do their job.
I look at other parties and see that it CAN be done, thus I find it ok to demand this from a company as resourceful as Microsoft.
The problem is they do things how it suits them, not how it suits the customers.