The Artima Developer Community
Sponsored Link

Weblogs Forum
Anatomy of Insanity?

23 replies on 2 pages. Most recent reply: Oct 17, 2004 8:56 PM by John D. Mitchell

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 23 replies on 2 pages [ « | 1 2 ]
Charles Haws

Posts: 24
Nickname: hawscs
Registered: Nov, 2003

Re: Anatomy of Insanity? Posted: Sep 12, 2004 4:19 PM
Reply to this message Reply
Advertisement
> > [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
> s 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.
>
> Vince.

I refer you to the original researchers again. The book is "Lean Software Development" by Mary Poppendieck. The point is made in several of the articles on their web site. They can make a better case than I can.

Short version: they're saying that two-thirds of software features are almost never used by anybody. Not that each user only uses one-third of a package, which you seem to have inferred.

Their argument, which is perhaps slightly off topic, is that un-agile methods force our customers (or marketers) to try and guess everything they might possibly need before any development takes place. This leads them to request everything but the kitchen sink. Agile methods, on the other hand, require keeping the feedback loop open, and responding to their actual needs. The customers prioritize the features that will add value. The studies quoted by the Poppendiecks indicate that a significant percentage of features aren't used by anybody, and another significant percentage of features are almost never used - by anybody. Taken together, those two percentages came out to about two thirds of the total features.

Their numbers, not mine. Seems credible to me, though. Sure, the percentages may vary, but I know I've written code that somebody asked for to cover themselves and nobody actually needed. They suggest that a feature that doesn't have an immediate purpose shouldn't get built.

They're very big on Scrum and iterative development in general, I believe. It's written at a level that can be understood by management as well as developers, so it doesn't cover quite the same details as the Agile Alliance - but the reasoning is very familiar, and very well explained.

As I said, they say it clearer than I do. Do not judge them solely based on my representation of them. If you read their ideas and still disagree, then we shall just agree to disagree.

Chaz

Charles Haws

Posts: 24
Nickname: hawscs
Registered: Nov, 2003

Re: Anatomy of Insanity? Posted: Sep 12, 2004 4:28 PM
Reply to this message Reply
> > 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.

I guess what I was trying to get at is this: I thought the feature in question was necessary and complex and I thought it was a terrible implementation of it because they did not have a good system for managing complexity.

>
> > [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.

I expect there's lots of ways that Undo could have been implemented, but I don't take as much fault with their implementation.

I take fault with their testing. At one point, they had a tester who could reproduce the bug, and a programmer who could not. That just shows poor communication.

The presence of a set of automated tests would have allowed the programmer to experiment with different alternative implementations - as you suggest, there have to be some better ones! The absence of such automated tests leads to the "don't fix what ain't broke" system. One is afraid to touch it because you have *no idea* what other side effects will occur.

I suppose I was too busy talking about it at a higher level in terms of managing complexity to actually list what I thought would have improved the situation. My apologies.

Rick Schaut

Posts: 2
Nickname: richs
Registered: Sep, 2004

Re: Anatomy of Insanity? Posted: Sep 13, 2004 8:39 PM
Reply to this message Reply
John,

First, if you want to create a new sniglet, I'd suggest a shorter word, like "complification". It's easier to pronounce, easier to spell and easier to remember. It might not quite have the legs of something like "ohnosecond," but it has possibilities.

Second, I should point out that I wrote that piece with a general audience in mind. Were I writing specifically for an audience of programmers, I’d have included a different set of details that would probably have shed different light on the general question you’ve asked than it does in its present form. I’d be careful about drawing any kind of significant conclusions based on my post. It certainly shed light on the issues, but, on its own, it’s merely anecdotal.

So, while your posed question is quite interesting, I think your answer falls off the mark. When we ask what could have been done differently, we have to realize that the original decisions were made within the context of a mini-max problem with very fuzzy constraints. The object is to produce something of “value” to people, and nearly everything you do, and I mean _everything_, has both a positive and a negative component with respect to some customers definition “value”.

The complexity of something like Word stems from the complexities inherent in that mini-max problem. Fred Brooks, who wrote “The Mythical Man-Month,” was the first to touch on this in the “No Silver Bullet” essay. He’s the one who talked about the difference between accidental and inherent complexity. And I have to tell you, even having been involved in the development of Word for the past 14 years, I have difficulty deciding whether even individual problems like the “Disk is Full” issue were merely accidental or inherent to the complexity of the problem domain.

This isn’t a question of either addiction or will, or, at least, it’s very difficult to conclude that it is a question involving some combination of addiction or will. You might want to consider that among the currently leading titles on software engineering are two that were written by Microsoft developers: “Code Complete” and “Writing Solid Code”. The first probably tops most people’s lists of titles, though I personally favor the latter. We’ve studied this process, and “What could we have done differently?” is a question we’ve asked ourselves over and over again. While we come up with incremental process improvements, I can say that our experience has done nothing but completely verify Brooks’ original points in the “No Silver Bullet” essay.

While it’s still something of an hypothesis, it does seem far more likely that complexity in software merely exists. It’s a reality with which we each must cope as best we can. One might as well claim that the aging process implies an addiction to growing old and the lack of will to overcome it. After all, if we weren’t addicted to growing old, we’d all simply get younger from time to time. Right?


Rick

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Anatomy of Insanity? Posted: Sep 13, 2004 9:21 PM
Reply to this message Reply
> 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.

And that leaves the problem of how to get "the will." When I saw you write this, I thought "okay, so I mentioned testing, and the debugger thing, but he doesn't think those will help; he wants to tackle root causes." That's fine, but it doesn't mesh well with my experience with teams.

Over and over again, I find that the best way to start initiating change in teams is not to tackle the root, but rather to help them tackle more immediate problems. When you do that, the team gains gut-level knowledge that things don't have to be as complicated as they currently are. That can help them develop the will to deal with bigger problems and the perception that those bigger problems really are problems. Most of the large changes I've facilitated in organizations have started with this sort of small change work.

Some organizations will tackle their bigger problems; others won't. For the ones that don't, usually it is still possible to improve and make work better and easier. It isn't la-la land, it's assessing obstacles with a cold eye and not giving them any more power than they have. Unfortunately, I think people do that when they adopt the stance you took above with your comments about the "complicatedness" of the organization, process, and software. When people say that nothing sort of addressing those things will do, they lose a place to start, and they lose leverage that could be used to get past them eventually.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Anatomy of Insanity? Posted: Sep 13, 2004 9:42 PM
Reply to this message Reply
Thanks for coming over to respond. Hopefully, this thread isn't just a big waste of time.

> First, if you want to create a new sniglet, I'd suggest a
> shorter word, like "complification". It's easier to
> pronounce, easier to spell and easier to remember. It
> might not quite have the legs of something like
> "ohnosecond," but it has possibilities.

Part of the point in using "complicatification", "complicatedness", and the like is that they literally embody the notion of complicatedness.

> Second, I should point out that I wrote that piece with a
> general audience in mind. Were I writing specifically for
> an audience of programmers, I’d have included a different
> set of details that would probably have shed different
> light on the general question you’ve asked than it does in
> its present form. I’d be careful about drawing any kind
> of significant conclusions based on my post. It certainly
> shed light on the issues, but, on its own, it’s merely
> anecdotal.

I've been in your shoes (though, I must say with a smaller user base :-) so I do have a lot of sympathy. Indeed, part of the reason that I picked your case is that your write up did a good job of explaining the process in a nicely accessible way. I.e., it comes across as being authentic.

> So, while your posed question is quite interesting, I
> think your answer falls off the mark. When we ask what
> could have been done differently, we have to realize that
> the original decisions were made within the context of a
> mini-max problem with very fuzzy constraints. The object
> is to produce something of “value” to people, and nearly
> everything you do, and I mean _everything_, has both a
> positive and a negative component with respect to some
> customers definition “value”.

Indeed. And so what you, your team, and your organization choose to use to make those "value" decisions is critically important and the context (economic, social, organizational, emotional, etc.) has a large influence in how you made/make those decisions.

> The complexity of something like Word stems from the
> complexities inherent in that mini-max problem. Fred
> Brooks, who wrote “The Mythical Man-Month,” was the first
> to touch on this in the “No Silver Bullet” essay. He’s
> the one who talked about the difference between accidental
> and inherent complexity. And I have to tell you, even
> having been involved in the development of Word for the
> past 14 years, I have difficulty deciding whether even
> individual problems like the “Disk is Full” issue were
> merely accidental or inherent to the complexity of the
> problem domain.

:-) Check out the java.net Bookclub Forum that I recently lead on _The Mythical Man-Month_:
http://www.java.net/cs/user/forum/cs_disc/1158

Anyways, the accidental vs. inherent complexity argument is basically a question of where one draws the line between need and want -- which brings up the whole issue of subjectivity (both individually, across groups, etc.). However, complicatedness, in this use, has the implication that the complexity (of whatever type) wasn't actually addressed. Basically the feeling is that a band-aid was put on a band-aid and the gangrene has been left to fester.

> This isn’t a question of either addiction or will, or, at
> least, it’s very difficult to conclude that it is a
> question involving some combination of addiction or will.
> You might want to consider that among the currently
> y leading titles on software engineering are two that were
> written by Microsoft developers: “Code Complete” and
> “Writing Solid Code”. The first probably tops most
> people’s lists of titles, though I personally favor the
> latter. We’ve studied this process, and “What could we
> have done differently?” is a question we’ve asked
> ourselves over and over again. While we come up with
> incremental process improvements, I can say that our
> experience has done nothing but completely verify Brooks’
> original points in the “No Silver Bullet” essay.

(A) To be clear, I'm not intending to particularly criticize you or your team. The point is to use this example to help get people to think about these issues. Kudos for having the courage to air this in public.

(B) Yes, I agree that Microsoft does have and has had some good people. That fact only has a relatively weak correlation to whether or not an organization is good.

(C) The proof is in the pudding.

> While it’s still something of an hypothesis, it does seem
> far more likely that complexity in software merely exists.
> It’s a reality with which we each must cope as best we
> e can. One might as well claim that the aging process
> implies an addiction to growing old and the lack of will
> to overcome it. After all, if we weren’t addicted to
> growing old, we’d all simply get younger from time to
> time. Right?

Nope. Addiction is about choice. At this point in time, humanity doesn't have a choice about aging. The question of addiction is in how we deal with aging. Taking a fatalistic position on either leads to unfortunate dysfunctions.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Anatomy of Insanity? Posted: Sep 13, 2004 10:09 PM
Reply to this message Reply
> And that leaves the problem of how to get "the will."
> When I saw you write this, I thought "okay, so I
> I mentioned testing, and the debugger thing, but he
> doesn't think those will help; he wants to tackle root
> causes." That's fine, but it doesn't mesh well with my
> experience with teams.

They help in conjunction with addressing the more fundamental issues. It's a matter of "and" rather than "or."

> Over and over again, I find that the best way to start
> initiating change in teams is not to tackle the root, but
> rather to help them tackle more immediate problems. When
> you do that, the team gains gut-level knowledge that
> things don't have to be as complicated as they currently
> are. That can help them develop the will to deal with
> bigger problems and the perception that those bigger
> problems really are problems. Most of the large changes
> I've facilitated in organizations have started with this
> sort of small change work.

Indeed. Now we're talking about change management and how to lead the horse to water in such a way as to induce them to drink. Of course, we're also now in a chicken-and-egg situation since it takes at least a small amount of will(ingness) to change to start tackling those problems.

> Some organizations will tackle their bigger problems;
> others won't. For the ones that don't, usually it is
> s still possible to improve and make work better and
> easier. It isn't la-la land, it's assessing obstacles
> with a cold eye and not giving them any more power than
> they have. Unfortunately, I think people do that when
> they adopt the stance you took above with your comments
> about the "complicatedness" of the organization, process,
> and software. When people say that nothing sort of
> addressing those things will do, they lose a place to
> start, and they lose leverage that could be used to get
> past them eventually.

There are two facets to that. One is that it is certainly true that we, as consultants, employees, etc. can have impact by working at whatever level that we are able to affect change. Starting small is a great way to do that.

The other facet is that in the long term there is an objective reality that does need to be addressed. It is, of course, completely up to people and organizations to choose how they wish to deal with that or ignore it. But there is a big difference in consciously choosing to focus on the small things while keeping the big picture in mind and obliviously ignoring the deeper issues.

Rick Schaut

Posts: 2
Nickname: richs
Registered: Sep, 2004

Re: Anatomy of Insanity? Posted: Sep 14, 2004 12:07 AM
Reply to this message Reply
> Thanks for coming over to respond. Hopefully, this thread
> isn't just a big waste of time.

You're welcome, though you get to take credit. You asked an interesting question.

> Part of the point in using "complicatification",
> "complicatedness", and the like is that they literally
> embody the notion of complicatedness.

Sorry. I was starting out with a bit of humor, and it seems as though you took it seriously. I gotta work on this humor without smiley's thing...

> Anyways, the accidental vs. inherent complexity argument
> is basically a question of where one draws the line
> between need and want -- which brings up the whole issue
> of subjectivity (both individually, across groups, etc.).

The words "technology" and "need" have never belonged in the same sentence together. The core of any technology question is the value proposition that it represents, and any value proposition is inherently subjective. This is especially true at what we would call the "leading edge" of technological change. Now, I think I can provide compelling arguments that these statements are true, but that would take an essay alone. Moreover, I don't think they're particularly controversial, so let's just assume that this is all about subjective notions of value. OK?

> However, complicatedness, in this use, has the implication
> that the complexity (of whatever type) wasn't actually
> addressed. Basically the feeling is that a band-aid was
> put on a band-aid and the gangrene has been left to
> fester.

I understand the source of that impression, but that was the point of the caution in my earlier remarks. There are some details I left out of the account that, to a professional, would have greatly reduced that impression.

> > This isn’t a question of either addiction or will, or,
> at
> > least, it’s very difficult to conclude that it is a
> > question involving some combination of addiction or
> will.

> (A) To be clear, I'm not intending to particularly
> criticize you or your team.

I didn't think that you were. Had I thought so, I wouldn't have bothered to respond.

Nor, for that matter, was my point about published works on software engineering intended to be a defense of either me or Microsoft. You are absolutely correct in saying that my aging analogy glosses over the distinction between choice and the lack of choice. On the other hand, if you want to say that the "complicatedness" is the result of a pathological issue at the organizational level, then you do need to show how particular decsions should have been made differently. The books I noted are very representative of the collective, organizational knowledge Microsoft has of the development process. While not being conclusive evidence in and of themselves, they do lead to the presumption that, at every decision point along the way, the best possible decision was made in terms of the trade-offs involved in any value proposition.

This is what I keep coming back to. I can't find any decision that we should have made differently in terms of the overall value proposition. Certainly, one can choose to completely rewrite Word at its core in order to fix the problem I outlined in "Anatomy of a Software Bug." But, does that choice make sense in terms of the overall value proposition? The answer is that it doesn't, because the redesign would result in a different set of problems that would lower the overall value of the product.

I should point out that this "value proposition" I keep talking about is always measured in terms of the customers. If we thought rewriting Word would result in something more people would want to use, we'd do it without hesitation even though the development cost would be high. We'd recoup that cost in the first month that the product would be available.

> (C) The proof is in the pudding.

Yes, it is. And Word currenly owns the word processing market on both the Windows and Macintosh platforms. I don't mean to be arrogant about this. I say this because we are, fundamentally, talking about a value proposition. That Word owns the market is pretty strong evidence that Word's value proposition is pretty high.

And, yes, there are network effects. Arguments about them aren't all that compelling. Any network effect argument one can make about Word is also applicable to WordPerfect. Compatibility isn't the hard nut to crack, even though people cite it all the time. The really hard nut to crack is the value proposition.

So, if I sound resigned to the inevitability of software complexity, it's not because I think it's not possible to reduce software complexity in a very practical, as opposed to purely theoretical, sense. It's because I've yet to find any reason to believe that reducing software compexity for the sake of reducing software complexity actually adds to the overall value proposition. This, I think, was Brooks' point in the "No Silver Bullet" essay.


Rick

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Anatomy of Insanity? Posted: Sep 30, 2004 12:53 PM
Reply to this message Reply
> Sorry. I was starting out with a bit of humor, and it
> seems as though you took it seriously. I gotta work on
> this humor without smiley's thing...

No worries. I have that same problem. :-)

> The words "technology" and "need" have never belonged in
> the same sentence together. The core of any technology
> question is the value proposition that it represents, and
> any value proposition is inherently subjective. This is
> especially true at what we would call the "leading edge"
> of technological change. Now, I think I can provide
> compelling arguments that these statements are true, but
> that would take an essay alone. Moreover, I don't think
> they're particularly controversial, so let's just assume
> that this is all about subjective notions of value. OK?

Bah. Is clean drinking water a subjective value? Maybe from the perspective of an alien anthropologist studying us. Is protection from predators (human and otherwise) a subjective value? How subjective are the benefits of the rule of law (be it de facto or de jure)?

Your response gets directly to my point. The arguments that you're making miss the real points while attempting to deal with them in a complicated manner. If I was a jerk, I might just thank you for proving my point and be done with it but I'm not so I'll continue with my rebuttal. ;-)


> > However, complicatedness, in this use, has the
> > implication
> > that the complexity (of whatever type) wasn't actually
> > addressed. Basically the feeling is that a band-aid
> > was put on a band-aid and the gangrene has been left to
> > fester.
>
> I understand the source of that impression, but that was
> the point of the caution in my earlier remarks. There are
> some details I left out of the account that, to a
> professional, would have greatly reduced that impression.

I guess that I have to say "yes and no" on that. I understand that you could share more mitigating information. The fact is that regardless of the circumstances, it still took y'all a bloody long time and effort to "really fix" the problem and you had a number of psuedo-fixes in the interim (which just increased the frustration and eroded the trust of the users suffering from the problem) and there's not much confidence that this sort of thing won't happen again (for example, for all of the "process" knowledge that MS has access to internally, what have you changed (like Michael's question about automated unit testing) which will fundamentally help?).

> Nor, for that matter, was my point about published works
> on software engineering intended to be a defense of either
> me or Microsoft. You are absolutely correct in saying
> that my aging analogy glosses over the distinction between
> choice and the lack of choice. On the other hand, if you
> want to say that the "complicatedness" is the result of a
> pathological issue at the organizational level, then you
> do need to show how particular decsions should have been
> made differently. The books I noted are very
> representative of the collective, organizational knowledge
> Microsoft has of the development process. While not being
> conclusive evidence in and of themselves, they do lead to
> the presumption that, at every decision point along the
> way, the best possible decision was made in terms of the
> trade-offs involved in any value proposition.

Hmm... You may think that that's the presumption that is (and/or should be) taken away but the proof really is in the pudding. Every user of MS Office has to deal with the complexity and complicatedness of MS Office everytime that they use it. Presumptions of technological prowess based upon anything but the actual products/services (and how they change (or not) over time) is basically just excuse making (and this is certainly endemic in our industry).

> This is what I keep coming back to. I can't find any
> decision that we should have made differently in terms of
> the overall value proposition. Certainly, one can
> choose to completely rewrite Word at its core in
> order to fix the problem I outlined in "Anatomy of a
> Software Bug." But, does that choice make sense in terms
> of the overall value proposition? The answer is that it
> doesn't, because the redesign would result in a different
> set of problems that would lower the overall value of the
> product.

That depends on how you calculate "value". I.e., if you don't care about how much time is wasted by the users of MS Office struggling through its complicatedness....

Also, that depends on whether or not a rewrite actually addressed the complexity and complicatedness problems. Hasn't MS and the MS Word team learned an amazing amount in the last 15 years that would help it create something more powerful, much less complicated, and arguably less complex?

> I should point out that this "value proposition" I keep
> talking about is always measured in terms of the
> customers. If we thought rewriting Word would result in
> something more people would want to use, we'd do it
> without hesitation even though the development cost would
> be high. We'd recoup that cost in the first month that
> the product would be available.

Always but not only. I.e., does security really matter? Does robustness really matter? Does usability really matter? Those don't necessarily directly drive increased users, revenue, or profits but they certainly affect them indirectly. Ah, so, then all of the attempts at quantifying their value is subjective (to y'all on the inside) even though they have objective (and subjective) effects on the users.

> > (C) The proof is in the pudding.
>
> Yes, it is. And Word currenly owns the word processing
> market on both the Windows and Macintosh platforms. I
> don't mean to be arrogant about this. I say this because
> we are, fundamentally, talking about a value proposition.
> That Word owns the market is pretty strong evidence that
> t Word's value proposition is pretty high.
>
> And, yes, there are network effects. Arguments about them
> aren't all that compelling. Any network effect argument
> one can make about Word is also applicable to WordPerfect.
> Compatibility isn't the hard nut to crack, even though
> people cite it all the time. The really hard nut to crack
> is the value proposition.

Sorry, you can't have it both ways. Those network effects and the monopoly power of the DOS/Windows platform played a large part in getting MS Word/Office into the dominant market position that it currently enjoys. Yes, of course there were other factors (such as WordPerfect's arrogance and incompetence :-).

Basically, how many MS Word users *love* it? How many people only use it because they are forced to because everybody they interact with use it? How many users curse it regularly?

Less subjectively... How many tens of millions of hours are wasted by MS Word users every year due to bugs? How many hundreds of millions of hours every year are wasted every year by the users having to (try to) deal with MS Word's complexity and complicatedness?

> So, if I sound resigned to the inevitability of software
> complexity, it's not because I think it's not possible to
> reduce software complexity in a very practical, as opposed
> to purely theoretical, sense. It's because I've yet to
> find any reason to believe that reducing software
> compexity for the sake of reducing software complexity
> actually adds to the overall value proposition. This, I
> think, was Brooks' point in the "No Silver Bullet" essay.

I don't recall any of us in this discussion talking about anything that was focused on anything but practically dealing with complexity (and complicatedness). My big abstract question revolved around suggesting that people note how the factors ("spirit" if you will) of an organization is made manifest in it's processes, products, and services.

It sounds like you have an underlying fatalism. I humbly suggest that you seriously reevaluate the distinction between complexity and complicatedness w.r.t. real simplicity.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Anatomy of Insanity? Posted: Oct 17, 2004 8:56 PM
Reply to this message Reply
[...]
> You might want to consider that among the currently
> y leading titles on software engineering are two that were
> written by Microsoft developers: “Code Complete” and
> “Writing Solid Code”. The first probably tops most
> people’s lists of titles, though I personally favor the
> latter.

Here's a couple of quotes that just came to mind:

"If you don't thoroughly understand the problem, you're not fixing the code." --Steve McConnell, Code Complete

"Nothing is more terrible than activity without insight." --Thomas Carlyle

Flat View: This topic has 23 replies on 2 pages [ « | 1  2 ]
Topic: Software Patents and "Open Source" Previous Topic   Next Topic Topic: I want an umpa lumpa. I want an umpa lumpa NOW daddy!


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us