Summary
Is the story of a bug in MS Word a sign of deeper dysfunction?
Advertisement
Earlier this year, Rick Schaut wrote about the history and process of finding a particularly annoying bug in MS Word in: Anatomy of a Software Bug. Now, it seems easy to pick on MS Word as being an example of "complicatification" and, well, it is. :-)
However, please read the article again and, if you would, think about how the software is a literal embodiment of the organization that created it. Sniff out all of the "code smells" explained in the article and chew on how the entire approach to "fixing" the various problems which cropped up only added to the complicatedness of the system.
Let me be so bold as to posit that there are two fundamental problems exhibited in this story (and, it goes without saying that most of us in this industry suffer from to one degree or another): addiction to complicatedness and a lack of will to deal with that addiction.
My immediate thought on reading the article is that it might have helped if they didn't have hardcoded calls against the OS API. If they worked against a simulated file system, they might have figured out sooner that the they were dealing with more than one open file limit.
It may seem a little hokey to put a layer between yourself and the APIs that you use. It isn't as easy as just using the API, but isolation layers pay for themselves in unexpected ways.
I think you're spot on that this is a story about the complexity of software.
But I wanted to offer a different conclusion than either "addiction to complication" or "a lack of will to deal with that addiction".
I once saw a very elegant proof that much of software complexity is *inherent* rather than *accidental*. Simply put, software has to model arbitrarily complicated domains - so software has all the complexity of the domain as well as all the complexity of the software.
So, to my mind, the question becomes how do we deal with unavoidable complexity? I think the industry as a whole still lacks tools to deal with that level of complexity. XP, Scrum, Agile Development in general, Test-Driven Development and Aspect-Oriented Programming come to mind as different focuses on creating these tools, but they're really not widespread as yet. Lots of programmers - the ones that don't read this kind of article for fun - have never heard of 'em.
I don't see this as an indictment of the team or the industry. I just see it as a good example of why the methods of the 90's aren't good enough. Fortunately, we have new methods to try and I suspect that a test-driven project wouldn't go through most of those same mistakes. Unfortunately, test-driven development is still a new idea to much of the software industry, but that's a question of time - it's got enough momentum now to prove itself one way or another in the next few years.
[Aside: Mary Poppendieck (poppendieck.com) quotes some very interesting numbers as far as estimating that 2/3rds of software features are never used. That would speak very well to your point about addiction to complexity. They have a lot to say about why projects implement unnecessary features and how to avoid it. But, this article was about an Undo feature and a Save feature on a multi-platform project combining with odd side effects. I think these features really are essential to the product. So I consider this inherent complexity rather than accidental - and I focused on the implementation question instead.]
> I think you're spot on that this is a story about the > complexity of software.
Actually, I don't think this is really a story of the complexity of software -- it's the story of the complicatedness of software. There's a distinction in implication between complex and complicated... In terms of this discussion, the distinction is between the necessary complexity (what you refered to as the "inherent" complexity) and the unnecessarily complicated. Another way to look at this is complicated stems from mere cleverness while (dealing with) complexity is a question of simplicity.
> [Aside: Mary Poppendieck (poppendieck.com) quotes some > me very interesting numbers as far as estimating that > 2/3rds of software features are never used. That would > speak very well to your point about addiction to > complexity. They have a lot to say about why projects > implement unnecessary features and how to avoid it. But, > this article was about an Undo feature and a Save feature > on a multi-platform project combining with odd side > effects. I think these features really are essential to > the product. So I consider this inherent complexity > rather than accidental - and I focused on the > implementation question instead.]
Well, there's certainly an addiction to quantity as the proxy for quality (which is fostered by the way things are marketed and sold, among other things).
Also, the assessment is relatively independent at the different levels. I.e., we can argue about the need for Undo separately from the issue of how Undo in a given system is designed and implemented.
> [Aside: Mary Poppendieck (poppendieck.com) quotes some > me very interesting numbers as far as estimating that > 2/3rds of software features are never used.
The glib implication of Peppendieck's claim is that two thirds of the functionality of the package could be removed without affecting its users.
This is one of those sweeping claims that, when looked at closely, doesn't bear scrutany. Whilst it may be true that I could buy a software package and not use two thirds of its features another user might not use a different two thirds, and so on for all users. In addition, I cannot often predict which features I will and won't use in the future as I gain experience with the package.
What I can say, is that when I buy a package I want it to be more capable of doing its stuff than I am. I don't want it to be a limiting factor on what I do. Therefore, such a package must necessarily have an excess of functionality, not just for me but for all its users.
If this were not that case, we would all be using "NotePad" to edit our documents and "Paint" to edit our pictures. They're reliable, they're simple, they're cheap. Unfortunately, they're not much use either.
Indeed, this is at the heart of my playful picking on Michael about YAGNI -- how do you decide when/where/etc. to draw the line between what's "necessary" and what's not. That is the question.
My contention in this thread is that the how and why of that decision at the organizational level is embodied in the hows and whys of the implementation (and testing and fixing and...). In the original example, there's an incredibly strong bias (for a number of "good" and "bad" reasons) that they (continute to) complicate the system.
> Indeed, this is at the heart of my playful picking on > Michael about YAGNI -- how do you decide when/where/etc. > to draw the line between what's "necessary" and what's > not. That is the question.
True, and I was pretty brief in my answer, but I notice that people get really serious about unit testing (testing each class independently, without the file system, etc) they get their isolation pretty much for free. They also don't have to depend on a debugger to find out what is happening they you can compose their decoupled pieces of software in a larger isolated test. In any case, I've heard from people at MS that test-driven is really infecting their culture there so hopefully things will get better.
> My contention in this thread is that the how and why of > that decision at the organizational level is embodied in > the hows and whys of the implementation (and testing and > fixing and...). In the original example, there's an > incredibly strong bias (for a number of "good" and "bad" > reasons) that they (continute to) complicate the system.
I agree. It looks like that is a real problem, but looking back on the article it seems that the design and organizational issues aren't the immediate hurdles or the bottlenecks. The immediate hurdles are direct dependence on the OS and reliance on the debugger. And, they've been Heisenbugged by those two things for quite a while.
> I agree. It looks like that is a real problem, but > looking back on the article it seems that the design and > organizational issues aren't the immediate hurdles or the > bottlenecks. The immediate hurdles are direct dependence > on the OS and reliance on the debugger. And, they've been > Heisenbugged by those two things or quite a while.
And, to be clear, I'll say that the reason why they were so "Heisenbugged" for so long is because of their organizational, design, and implementational addiction to complicatedness rather than to actually dealing with problems.
All these glib generalities. It is always easy to generalize about someone else's problems.
I don't see how doing unit tests first or abstaining from the use of a debugger would have solved these specific problems. It sounds like the original problem was kind of difficult to isolate and required a few high level interactions. Isn't that the kind of thing that unit testing doesn't address?
The fact is that maintaining simplicity in the software for a large and complex application is an incredibly difficult task on many levels. It takes time, skill, diligence, patience and more.
> I don't see how doing unit tests first or abstaining from > the use of a debugger would have solved these specific > problems. It sounds like the original problem was kind > of difficult to isolate and required a few high level > interactions. Isn't that the kind of thing that unit > testing doesn't address?
It wouldn't have solved the root causes, but it would've helped them get past the cascading problems. I agree with John that there are bigger issues, but, according to the article, they took several months trying to nail down the problem using manual testing and they only found it when they automated the interaction. Their use of the debugger hid the problem. If they'd been able to find out what they needed without the debugger they might've been better off.
You're right about unit tests. They alone wouldn't have found the issue, but if tests had led them to decouple their code from the OS API, they could have written the setup to run their whole application against existing mocks and said "huh, we're running exactly the same code in both cases and it fails in one. What's different?"
> The fact is that maintaining simplicity in the software > for a large and complex application is an incredibly > difficult task on many levels. It takes time, skill, > diligence, patience and more.
Sure does, so I don't think we should discount anything that helps.
Glib? No, I meant everything that I've said in this thread.
Unit testing, debuggers and other inspection tools, reviews, test documents, etc. are all just tools. If there's no underlying will to address the complicatedness (let alone the fundamental complexities) of the organization, its processes, and the software it creates then the tools won't help much and will often exacerbate the confusion.
> Unit testing, debuggers and other inspection tools, > reviews, test documents, etc. are all just tools. If > there's no underlying will to address the complicatedness > (let alone the fundamental complexities) of the > organization, its processes, and the software it creates > then the tools won't help much and will often exacerbate > the confusion.
Yes, it is necessary to have the will to do something about the complicatedness (and complexity) to really solve the problems. Note, though, that the will doesn't have to be some big, heavy, "marketing", or otherwise emotional production. Without that will, we're just flailing around in la-la-land.
Do you have some case(s) in mind where you don't think this is true?
Flat View: This topic has 23 replies
on 2 pages
[
12
|
»
]
Previous Topic
