This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: This is a little too facile for my taste
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
That's a tough question to answer. Why? Because every bug has a different story about why it's in there.
And, believe me, every bug does have a story. Fixing code isn't easy and don't think that Open Source would fix the issues any better than Microsoft's own developers can (they might fix bugs better, but then you'd have other interesting problems that you didn't consider before -- for instance, training costs. 100 million people have existing Windows. What happens if you throw a new version of the operating system out there every week? Does that cause problems that you didn't forsee?).
I don't think this has anything to do with Open Source, closed source, or unforeseen consequences - at least not for the most part. While our Smalltalk products have much, much smaller codebases, most of our unadressed bugs come down to resource allocation issues - given this bug over here, and the need for that new feature over there, we have to balance the engineering resources against the perceived needs of customers. That's difficult, since our perceptions don't necessarily match the big picture perfectly - and to the person or team suffering from a given bug, our focus can look completely wrong. My guess is that MS has much the same problem. Sure, their resource base is much bigger - but at a certain point, adding people to a development team just makes things worse, not better. Here's how Scoble puts it:
Some bugs get put off until the future, too, because it means changing something underlying everything, which means that that code would need to go through massive testing. Or, because everyone knows that there's a new product or technology coming that'd fix the issue. My educated guess is that this is the case with the file-names-that-start-with-periods problem that Jeff answers (Longhorn will come with a technology that should fix this problem, for instance).
There are UI issues in VW (take the Dataset, please!) that have this problem. Pollock is the fix for that and a raft of other UI issues - which means that, in the meantime - users of VW have to suffer with what we have. Every development team faces a variation on this theme. The part that torques people off is when - because of changed circumstances - the fix you've been touting for quite awhile never comes to pass. Maybe there was a strategy change, or the market moved - but either way, the new project that would "fix all problems" never comes to pass, and the users are left with the same unaddressed bugs. In my experience, many of these changes are for reasons that really irritate users (The PPD merger killed Van Gogh, for instance) - but at the time they made sense to the parties involved in the decision making process.
The bottom line is, it's almost never as simple as just drop other things and fix the blasted bug!.
Previous Topic
