Discussions

News: Ward Cunningham Interview: Refactoring the business

  1. Jon Udell interviewed Ward Cunningham (of XP and Wiki fame). They talk about refactoring, and XP, but the opportunity that Ward sees ahead transcends the XP debate. He sees an opportunity to script the enterprise in business terms as well as in IT terms.

    Read Jon Udells Column: Refactoring the business

    Jon also has a blog that goes into some outtakes that he didn't put in his column. Here he goes into:

    - On knowing what's good enough
    - On old habits
    - On correctness, testing, and knowledge representation
    - On interpreting business information

    Read the Ward Cunningham Outtakes

    Do you agree with Wards view that:

    "There is a huge opportunity lurking up ahead. The enterprise guys don't know it because they think scripting is for sissies. The scripting guys don't know it because they think business problems are already simple and don't have to be made that way."

    Threaded Messages (19)

  2. Simplicity rules again[ Go to top ]

    This short article just shows Ward's tendency towards simplicity. Ward has touted simplicity as the one idea that has the greatest ability to push a business up to the next level, no matter what the business. Part of the problem that I see is that business values complexity, and not necessarily in a good way.

    More and more, today, programmers value simplicity. The Agile movement in particular has returned simplicity to the forefront: simpler languages, simpler implementations, simpler designs... the goal is to defer true complexity as long as possible. The benefits include ease of maintenance, ease of understanding, ease of dealing with change.

    From a poor programmer's perspective, businesses -- and in particular middle management -- loves complexity. The more complexity there is, the greater opportunity there is to appear the hero. I have never seen a complement to "Egoless Programming" in the business world. Individuals base their careers around their ability to wade through complexity, whereas it would be even better to go one step further and reduce that complexity. As long as business and business-people continue to see managing (not eliminating) complexity as heroism, then nothing will change.

    Shame, too, because simplicity is just really so much better.
  3. Simplicity rules again[ Go to top ]

    <JB>

    As long as business and business-people continue to see managing (not eliminating) complexity as heroism, then nothing will change.

    </JB>

    Good point!
  4. Simplicity rules again[ Go to top ]

    <JB>

    As long as business and business-people continue to see managing (not eliminating) complexity as heroism, then nothing will change.

    </JB>

    I think sun can take printout of the above lines and past it on the desktop of every member of petstore development team !
  5. Simplicity rules again[ Go to top ]

    <Rainsberger>
    This short article just shows Ward's tendency towards simplicity. Ward has touted simplicity as the one idea that has the greatest ability to push a business up to the next level, no matter what the business. Part of the problem that I see is that business values complexity, and not necessarily in a good way.

    More and more, today, programmers value simplicity.
    </Rainsberger>

    There is a subtle but important difference between simplicity and "as simple as possible but no more". The tone of your comments appear to favor the former approach, which I believe is dangerous to business.

    The reality I've seen is that most businesses are not complex because the people in them want them to be. Instead, they're complex because they need to be to compete.

    The trick for developers and their managers is not to come up with simple solutions. In the business environments I work in, simple is not going to win you contracts, or get you efficiencies, or open new lines of business. Instead, the trick is to come up with solutions that are as simple as possible, but with enough flexibility to "bend" with the business as needed.

    Certainly there is alot of unnecessary complexity in business, both in businesses themselves and code written to support them. But let's not have a knee-jerk reaction and say all of the complexity can and should be eliminated - becuase that's naive and it's not going to help anyone.

    <Rainsberger>
    As long as business and business-people continue to see managing (not eliminating) complexity as heroism, then nothing will change.
    </Rainsberger>

    I've seen what you're describing here, but I think you're overstating it just a tad. Frankly, it appears to me that you're villainizing corporate america to further developer buy-in to Agile development. Most people I've worked with, IT and non-IT, strive to both eliminate unneeded complexity and at the same time keep fulfilling necessary requirements.

    But their efforts often get derailed by suggestions such as yours to radically attack complexity with more simple designs. They're trying to cope with an evolutionary approach, you are advocating a revolutionary one. But often a "revolutionist" manages to convince some key person that this is the way to go, and it isn't until 6 months into the project that everyone realizes that the new solution is indeed simple - so simple that it can't handle the business needs.

    How often have we seen the "next big thing" come in to revolutionize the business, slash costs, make things easier - and then see front-line people sneaking into the old system because the new one doesn't work, or is missing key features they need to get their jobs done?

    In closing - saying "simplicity is so much better" is such a trite thing that I'm at a loss to even respond.

    As for the article itself - there's nothing new there that I see. People have been working for code-less or nearly codeless programming environments for literally decades. CASE tools, visual programming, you name it - it's been tried. And the scripting vision shown shares the same problems as the CASE tools and visual programming tools. In this case - scripting makes the easy things easy, but the hard often becomes close to impossible. Performance and scalability concerns often rear their ugly heads. We all _want_ clean, easy to read object models - but the sad truth is that those clean models often don't work well (or at all) on current hardware. Yes, there is in every system ugliness and twisted code that doesn't have to be there. But there's also code that's hard to read because that was needed to get the job done.

         -Mike
  6. Simplicity rules again[ Go to top ]

    <quote>
    There is a subtle but important difference between simplicity and "as simple as possible but no more". The tone of your comments appear to favor the former approach, which I believe is dangerous to business.
    </quote>

    I don't believe that I was advocating simple implementations that don't solve the business problem at hand. Sometimes the business problem is complex, but all too often, we are pushed to deliver complex solutions to simple problems. I have not seen the benefit to this, although I have seen the benefit to delivering simple solutions to simple problems.

    If we pretend that all problems have simple solutions, then the resources we save solving the 98% of problems that are simple will more than suffice to tackle the 2% of problems that truly are that complex.

    My hypothesis is that business values managing complexity over reducing it; therefore, the situation is not likely ever to improve.

    <quote>
    Instead, the trick is to come up with solutions that are as simple as possible, but with enough flexibility to "bend" with the business as needed.
    </quote>

    You appear to say that it is necessary to deliver solutions that solve future business problems. I don't think that that is possible, so I don't try. I don't have the necessary clairvoyance.

    If I solve today's problem quickly, cleanly and simply, then I can solve tomorrow's problem all the more quickly, without throwing away today's solution.

    <quote>
    Certainly there is alot of unnecessary complexity in business, both in businesses themselves and code written to support them. But let's not have a knee-jerk reaction and say all of the complexity can and should be eliminated - becuase that's naive and it's not going to help anyone.
    </quote>

    I have to admit that I cannot find in my original note where I wrote the above. Could you point it out to me? I can find where I wrote about Ward's "tendency towards simplicity" and that business "values complexity" and that we should "reduce complexity", but I'm having trouble finding the part where I wrote that all complexity must be eliminated.

    <quote>
    I've seen what you're describing here, but I think you're overstating it just a tad. Frankly, it appears to me that you're villainizing corporate america to further developer buy-in to Agile development.
    </quote>

    "Villainizing?" Far too dramatic. I wrote that business appears to value managing complexity as opposed to reducing it. If that were not true, then we would not have books like Taiichi Ohno's "Toyota Production System". If that were not true, then Lean Manufacturing and Lean Development should surely be "the way we do things" and not foreign concepts.

    I would appreciate your refraining from putting value judgements in my mouth (or words, as it were).

    <quote>
    But their efforts often get derailed by suggestions such as yours to radically attack complexity with more simple designs. ... and it isn't until 6 months into the project that everyone realizes that the new solution is indeed simple - so simple that it can't handle the business needs.
    </quote>

    Anyone that advocates an implementation that does not solve the business problem must be promptly fired. I don't see how people can argue against that, and certainly I am not doing so.

    Simple designs can solve sizable problems. It has been done. It is being done, somewhere. It will be done again. Ward's WyCash story, as told in Kent Beck's work, is an example. One day to enable multiple currency support in a system that was designed never even to consider the problem. A simple, well-factored system can handle such a change.

    I worked on an e-commerce platform that does, among other things, product discounts. There was built an entire "product discount framework" that consisted of a few relatively simple tables and was remarkably flexible. You could create a tiered discount that mixed straight cash reduction and percentage cash reduction. The tiers could be based on quantity of product, amount of order or weight of the products to be shipped. A thing of beauty.

    Unfortunately, use case #1 was "Buy one get one free". The solution could not do "Buy one get one free".

    The bottom line is that solving the problem is more important than considering simple solutions versus complex solutions. It is easier to solve targeted business problems with simpler solutions. Therefore, we should start with a simple solution, rather than some arbitrary complex implementation (which may or may not be a solution). That's all. Quite logical, I think.

    In other words, walk first, then run. Then consider entering the marathon.

    <quote>
    How often have we seen the "next big thing" come in to revolutionize the business, slash costs, make things easier - and then see front-line people sneaking into the old system because the new one doesn't work, or is missing key features they need to get their jobs done?
    </quote>

    Poorly-implemented solutions invalidate the goals? It is easy do things poorly, compared to doing them well, especially when they are new things. We should give up because we haven't figured out how to do the new things properly?

    We wouldn't be able to have this conversation if everyone thought that way.

    <quote>
    Yes, there is in every system ugliness and twisted code that doesn't have to be there. But there's also code that's hard to read because that was needed to get the job done.
    </quote>

    I agree: sometimes complexity is required. The goal is to defer complexity until it is required, rather than putting it on page one, as many people do. (We've both seen it, I'm sure.) I think that's what I wrote in my original note, actually.

    I just checked. Yep.
  7. Simplicity rules again[ Go to top ]

    <Rainsberger>
    Sometimes the business problem is complex, but all too often, we are pushed to deliver complex solutions to simple problems.
    </Rainsberger>

    Two quick remarks on this:

    1) Perhaps you've seen this in a company like IBM, which has something like 200,000+ employees. In most companies, complexity isn't usually pushed upon developers when the problem space is simple - the developers usually invent the complexity all by themselves.

    2) If the problem is indeed simple, then it shouldn't be very difficult to re-engineer the initial cut if it's too complex. This is almost so obvious that it shouldn't need to be stated.

    Indeed - I don't think many people are worried about solutions to simple problems. For those who are, hats off to ya. For the rest of us, the problem lies in solving complex solutions in a managable way.

    <Rainsberger>
    You appear to say that it is necessary to deliver solutions that solve future business problems. I don't think that that is possible, so I don't try. I don't have the necessary clairvoyance.
     
    If I solve today's problem quickly, cleanly and simply, then I can solve tomorrow's problem all the more quickly, without throwing away today's solution.
    </Rainsberger>

    I've heard this argument before, and it holds for University students, but not for people with years of industry experience.

    For example, Fowler recently had an interview on Artima where he pointed to a paper he did about favoring simple, hard coded solutions whenever possible. His closing example was sales discount code. He said it was preferable to hard-code discount levels from initial requirements than creating a more flexible solution up front.

    My counter-argument is that anyone who has ever worked on a sales system _knows_ in his heart of hearts that discount plans change often - sometimes on a weekly basis. Only the greenest of developers would be naive enough to assume that 3 hard coded discount plans (from his example) would suffice for a production system.

    So I say - no, we can't be clairvoyant. At the same time, we shouldn't ignore the blindingly obvious just to satisfy a software development methodology. If you do, and follow requirements literally like a robot, as the project moves forward it will either be drowned in constant refactoring, or the developers will continue bolting increasingly complex code on a framework that wasn't designed to support it. Perhaps for a consultant continually re-writing the same code over and over again is appealing - hey, steady contract work! - but I don't think it's very appealing to many others.

    <Rainsberger>
    I have to admit that I cannot find in my original note where I wrote the above. Could you point it out to me? I can find where I wrote about Ward's "tendency towards simplicity" and that business "values complexity" and that we should "reduce complexity", but I'm having trouble finding the part where I wrote that all complexity must be eliminated.
    </Rainsberger>

    There is no such quote. At the same time, many of your posts on this topic and others don't seem to acknowledge that many problem domains are just plain inherently complex.

    So - everyone agrees simplicity is good. The question on everyone's mind is - what do you do when you can't take the easy, simple way out?

    <Rainsberger>
    "Villainizing?" Far too dramatic. I wrote that business appears to value managing complexity as opposed to reducing it.
    </Rainsberger>

    You chose the drama, not I. As one paragraph of yours opened: "From a poor programmer's perspective, businesses -- and in particular middle management -- loves complexity. The more complexity there is, the greater opportunity there is to appear the hero. I have never seen a complement to 'Egoless Programming' in the business world."

    The poor programmer? The hero? These aren't objective, emotionally-neutral terms.

    <Rainsberger>
    I would appreciate your refraining from putting value judgements in my mouth (or words, as it were).
    </Rainsberger>

    Phrases like "poor programmer", repeated use of the word "hero", and describing management career tracks in terms of heroically advocating complexity already convey strong value judgements. If you wish to have a more objective discussion you should refrain from usually emotionally charged phrasing.

    <Rainsberger>
    Anyone that advocates an implementation that does not solve the business problem must be promptly fired. I don't see how people can argue against that, and certainly I am not doing so.
    </Rainsberger>

    Wow, I'm glad I don't work for you. You must go through 3-4 of your people a week with that attitude.

    <Rainsberger>
    Simple designs can solve sizable problems. It has been done. It is being done, somewhere. It will be done again. Ward's WyCash story, as told in Kent Beck's work, is an example. One day to enable multiple currency support in a system that was designed never even to consider the problem. A simple, well-factored system can handle such a change.
    </Rainsberger>

    Sure. I don't think anyone is disputing that some problem domains have simple, elegant solutions to them. At the same time, please don't represent such situations as so common that they are the norm.

    <Rainsberger>
    I worked on an e-commerce platform that does, among other things, product discounts. There was built an entire "product discount framework" that consisted of a few relatively simple tables and was remarkably flexible. You could create a tiered discount that mixed straight cash reduction and percentage cash reduction. The tiers could be based on quantity of product, amount of order or weight of the products to be shipped. A thing of beauty.

    Unfortunately, use case #1 was "Buy one get one free". The solution could not do "Buy one get one free".

    The bottom line is that solving the problem is more important than considering simple solutions versus complex solutions. It is easier to solve targeted business problems with simpler solutions. Therefore, we should start with a simple solution, rather than some arbitrary complex implementation (which may or may not be a solution). That's all. Quite logical, I think.
    </Rainsberger>

    From my viewpoint, this means you valued the developer's sense of "A thing of beauty" over the business requirements. Your beautiful solution couldn't handle use-case #1. Sounds to me like someone should be fired!!!!

    So - you're saying that business should change it's way of business to accomodate the "poor developer". The poor developer - the salesmen want to have buy-one-get-one-free promotions! The nerve of those guys. Don't they know "simple solutions" the XP way are the way software should be developed? Hell - they should refactor their business to get rid of those silly complexities. They may lose revenue, but all the programmers will be happy now. And then I can write a white paper on how successfull the software project was!! Hooray!

    <Rainsberger>
    Poorly-implemented solutions invalidate the goals? It is easy do things poorly, compared to doing them well, especially when they are new things. We should give up because we haven't figured out how to do the new things properly?

    We wouldn't be able to have this conversation if everyone thought that way.
    </Rainsberger>

    No - people shouldn't believe every snakeoil salesman that says his simple solution will easily replace the complex solution that actually works.

    <Rainsberger>
    I agree: sometimes complexity is required. The goal is to defer complexity until it is required, rather than putting it on page one, as many people do. (We've both seen it, I'm sure.) I think that's what I wrote in my original note, actually.
    </Rainsberger>

    Please forgive me, but I'm going to even more blunt than usual now. What you're advocating is kindergarten programming. What you describe as a "thing of beauty", business people will call a "limited, crippled system that's of no use to my business".

    Listen - I'm a big advocating of small iterations, and phasing features into a project over time. I realize it's a mistake to try to do everything all at once. But at the same time, there _are_ minimum requirements for any system that must be there for it to be usable for the target users. The scenarios you've described purposely crippled a system so the designers could feel their sense of beauty. Specifically - you happily ignored the very first use-case in your system, even though it was obviously well-known up front. Your business people apparently stated what they needed for the system to work in their environment - and you didn't deliver. This is only exacerbated by the absurdity of the example - any child understands the concept of buy one get one free, and yet you couldn't code it?

    Please sir, go sell it somewhere else. Your notion of "simplicity" would frankly bankrupt any of the companies I do work for.

        -Mike
  8. Simplicity rules again[ Go to top ]

    <quote>
    1) Perhaps you've seen this in a company like IBM, which has something like 200,000+ employees. In most companies, complexity isn't usually pushed upon developers when the problem space is simple - the developers usually invent the complexity all by themselves.
    </quote>

    Market pressure (both time and the need to solve every problem at once) generally drives programmers to deliver complex solutions. This is typically more of problem in the shrink-wrap world, I admit.

    As you say, part of the problem is telling programmers not to invent complexity. We haven't licked that one yet.

    <quote>
    2) If the problem is indeed simple, then it shouldn't be very difficult to re-engineer the initial cut if it's too complex. This is almost so obvious that it shouldn't need to be stated.
    </quote>

    Equally obvious is that there should be no need to re-engineer the solution to a simple problem, no? This appears to be a very simple situation in which applying the maxim that you state is good only for university students would save the company some hard cash.

    <quote>
    I've heard this argument before, and it holds for University students, but not for people with years of industry experience.
    </quote>

    Could you please stop this pointless rhetoric and stick with the actual substance of the conversation?

    I assume that you mean something like, "It is not my experience that 98% of business problems are as simple as this quote makes them out to be" or some such. That is the point of the remark, though. Don't take "98" and "2" so literally. Most problems aren't really that complex. If we just started treating them as simple, then we can save our energy for truly complex problems.

    <quote>
    So I say - no, we can't be clairvoyant. At the same time, we shouldn't ignore the blindingly obvious just to satisfy a software development methodology. If you do, and follow requirements literally like a robot, as the project moves forward it will either be drowned in constant refactoring, or the developers will continue bolting increasingly complex code on a framework that wasn't designed to support it. Perhaps for a consultant continually re-writing the same code over and over again is appealing - hey, steady contract work! - but I don't think it's very appealing to many others.
    </quote>

    If I don't follow requirements literally, how should I follow them? This is, in my opinion, a key question, because it points to something that doesn't appear to make much sense: the notion that programmers should tell business people what business problem they need to solve. If the programmer ALSO has the requisite business experience, then I have no problem with that; however, I continually see programming groups that are charged with the task of deciphering or even discovering (!) the business problem that they are supposed to solve. Does this sound like an effective approach? Is not the point for business to request a solution and IT to provide it? (I speak of in-house IT work. In the shrink wrap world, where I lived for several years, we have to predict the future. That's one reason why I left it.)

    So if IT cannot trust the business to make their requirements known, then how can IT know what problem to solve? I suppose it can grow the business skill internally, but that seems wasteful when there's plenty of business skill available. (If none such is available, then I don't suppose it matters which side specifies the problem, just as long as someone does it.)

    <quote>
    <Rainsberger>
    "Villainizing?" Far too dramatic. I wrote that business appears to value managing complexity as opposed to reducing it.
    </Rainsberger>

    You chose the drama, not I. As one paragraph of yours opened: "From a poor programmer's perspective, businesses -- and in particular middle management -- loves complexity. The more complexity there is, the greater opportunity there is to appear the hero. I have never seen a complement to 'Egoless Programming' in the business world."

    The poor programmer? The hero? These aren't objective, emotionally-neutral terms.
    </quote>

    OK. I opened the door. Let me close it and get back to the issue. It is my observation that business values complexity, based on the way business people use their management (not reduction) of complexity as status symbols and based on the fact that they are often promoted because of it. It is similar to the problem that "Face time" is often a better determiner of a worker's success in an organization than, say, objective effectiveness as measured in terms of dollars saved.

    <quote>
    <Rainsberger>
    Anyone that advocates an implementation that does not solve the business problem must be promptly fired. I don't see how people can argue against that, and certainly I am not doing so.
    </Rainsberger>

    Wow, I'm glad I don't work for you. You must go through 3-4 of your people a week with that attitude.
    </quote>

    Do you advocate needless complexity? If you do, then do you find that to be effective? I see it like trying to hit the lottery: if I spend enough time building complex solutions under the guise of flexibility, then eventually I'll deliver some much-needed flexibility to someone who needed it. What is lost in the shuffle is all the needless flexibility that did nothing more than cost someone money. That's the complexity I want to reduce. I don't know how that could be a contentious issue.

    <quote>
    From my viewpoint, this means you valued the developer's sense of "A thing of beauty" over the business requirements. Your beautiful solution couldn't handle use-case #1. Sounds to me like someone should be fired!!!!

    So - you're saying that business should change it's way of business to accomodate the "poor developer". The poor developer - the salesmen want to have buy-one-get-one-free promotions! The nerve of those guys. Don't they know "simple solutions" the XP way are the way software should be developed? Hell - they should refactor their business to get rid of those silly complexities. They may lose revenue, but all the programmers will be happy now. And then I can write a white paper on how successfull the software project was!! Hooray!
    </quote>

    Well, I didn't build that solution, not that it matters. It was back in the day before I was allowed to touch such things: I was still a student. At least we agree that not solving the business problem is a bigger concern than how flexible the "solution" is.

    As for the next paragraph, I honestly cannot tell where it came from. "Buy one, get one free" is a simple business problem to solve. I would solve it with a very simple solution, and not some big discounting framework. I don't see the leap to the programmers telling business that they are too complex.

    From this point, you decided that it was more important to attack me rather than argue the points, so I'll close by saying that we agree on some points, but you appear to think that I advocate "simple at the cost of delivering business value". I do not. I advocate simple SOLUTIONS: that word implies solving the business problem.

    Delivering simple solutions is tough work. Don't feel bad if you haven't done it. I haven't done it as much as I'd like, and I don't feel bad for it. I just try to do better work the next time, and so far, I have.
  9. Simplicity rules again[ Go to top ]

    <Rainsberger>
    If I don't follow requirements literally, how should I follow them? This is, in my opinion, a key question, because it points to something that doesn't appear to make much sense: the notion that programmers should tell business people what business problem they need to solve. If the programmer ALSO has the requisite business experience, then I have no problem with that; however, I continually see programming groups that are charged with the task of deciphering or even discovering (!) the business problem that they are supposed to solve. Does this sound like an effective approach? Is not the point for business to request a solution and IT to provide it? (I speak of in-house IT work. In the shrink wrap world, where I lived for several years, we have to predict the future. That's one reason why I left it.)

    So if IT cannot trust the business to make their requirements known, then how can IT know what problem to solve? I suppose it can grow the business skill internally, but that seems wasteful when there's plenty of business skill available. (If none such is available, then I don't suppose it matters which side specifies the problem, just as long as someone does it.)
    </Rainsberger>

    Here's the problem - miscommunication. For any non-trivial application, the requirements are going to be fairly complex. And in that sort of scenario, things can be lost, mistakes can be made. I don't advocate that developers go off on their own and ignore requirements, but I _do_ advocate that developers question things that go against their experience and seek clarification. I've seen a number of situations where the business side has glossed over huge parts of the application because they "just assumed" everyone knew about it.

    I know - this sort of thing should be caught before a developer ever sees it. But often minor details slip through - details that have big implications.

    There is also the problem of general disconnects between developers and non-IT people. Having 35 years of experience in trading commodities (or whatever) is _not_ the same as building a trading system. We may expect business people to deliver requirements in a well-ordered, detailed fashion, but in reality that doesn't happen, and the development team and the business people need to work together to smooth out the areas where disconnects are happening.

    Bringing this back around to where this started - it is common to see a "simple" requirement and for developers to create a corresponding simple solution - only to find that problem space was not so simple, but the person defining the requirements did a bad job of communicating it.

    <Rainsberger>
    From this point, you decided that it was more important to attack me rather than argue the points, so I'll close by saying that we agree on some points, but you appear to think that I advocate "simple at the cost of delivering business value". I do not. I advocate simple SOLUTIONS: that word implies solving the business problem.
    </Rainsberger>

    Well, I apologize for the latter half of that post. I went off on a rather bizarre tangent and get caught up in my own positive feedback loop. Sorry about that.

    <Rainsberger>
    Delivering simple solutions is tough work. Don't feel bad if you haven't done it. I haven't done it as much as I'd like, and I don't feel bad for it. I just try to do better work the next time, and so far, I have.
    </Rainsberger>

    I understand what you're saying here, but I think you're muddying up different things. There are different types of problems, and different levels of complexity in solutions. You can't lump them all together.

    That said....simple problems are a non-issue to me. As I said before, if the problem set is indeed simple then it doesn't matter what the solution is - because if the current solution really bad, it should be simple to fix it.

    For more complex problems, things aren't nearly as clear. You keep going back to simple solutions, and I'll agree again that they're great - when the problem can accomodate it. But not all complex problems can be solved simply. Period. Full stop.

         -Mike
  10. flawed logic[ Go to top ]

    \begin[italicize]

    \author{Mike Spille}
    Indeed - I don't think many people are worried about solutions to simple problems. For those who are, hats off to ya. For the rest of us, the problem lies in solving complex solutions in a managable way.
    \end


    This paragraph demostrates your fallacy. I don't know if you are trying pull a fast one, but my sophistry meter hasn't gone off, so I'll assume the problem is that you are simply blinded by your infatuation with complexity (i.e., large paychecks.)

    You quickly dismiss simple problems. Nobody's worried about them. But instead of solving complex \emph{PROBLEMS}, you're dead set on a complex \emph{SOLUTION}. A problem and a solution are not interchangeable. Simple problems sometimes have complex solutions. Complex problems often have simple solutions. Sometimes, a complex solution is used when a simpler one is available. Very often, complexity solutions are the result of not understanding the problem, whether it be simple or complex.

    While you are deliberately putting straw men arguments into others' words, which are not only ridiculous, but were not even there in the first place (which is a form of unneeded complexity in itself), what I have enunciated above are a few simple facts that you refuse to acknowledge, and either consciously or unconsciously try to confuse the issue with spurious and irrelevant accusations.

    My point?

    Sometimes the answer is simple, even to complex problems. And no one is trying to steal your paycheck.
  11. flawed logic[ Go to top ]

    <Evans>
    You quickly dismiss simple problems. Nobody's worried about them. But instead of solving complex \emph{PROBLEMS}, you're dead set on a complex \emph{SOLUTION}. A problem and a solution are not interchangeable. Simple problems sometimes have complex solutions. Complex problems often have simple solutions. Sometimes, a complex solution is used when a simpler one is available. Very often, complexity solutions are the result of not understanding the problem, whether it be simple or complex.
    </Evans>

    ...and sometimes, it rains :-)

    Seriously - you've given a very convincing argument suitable for a write up in a course on logic. But I don't see it's applicability here.

    When I speak of simple problems, I am _not_ speaking as an algorithms professor describing the travelling salesman problem. I'm talking about business problems and IT solutions to them. In that realm, a "problem" isn't a one liner like "joe needs to visit these 4 cities - what's the shortest path?". The problem is a list of requirements, and you can generally eyeball the requirements and tell fairly quickly if this is a complex problem or a simple, rote one.

    Here's an example of a simple problem: a big investment bank wanted a "webbified" document system. The ability to upload/download files, see lists of files, etc. The requirements were about 20 pages long in total - mostly rote detail that wasn't any big deal. They wanted a custom system because they didn't want to shell out big $$$ for a commercial package, and they wanted alot of silly customization and the ability to easily hang it off of their intranet site. There was a lot of grunge work involved, but ultimately it was a simple problem. My team developed it in 5 weeks (2 1/2 developers), no muss no fuss.

    Here's a not so simple problem: an equities order system which needs to integrate with 5 existing systems. Ignoring complex functional details (it would take too long to go into the vagarities of equity securities), it also has to hook into these 5 very different systems, support 3000 users, and support 500 transactions per second during market activity bursts. It also has to be highly available, in the strictest sense of HA that you can think of.

    I happily pumped out the doc management solution in 5 weeks. I did not tout or advocate complexity to extend my paycheck. I used a simple solution because it fit a simple problem. But now I'm heavily involved in a system that is, indeed, by _anyone's_ measurement system complex. There is no simple solution to this - there's a combination of many solutions that all have to work together seamlessly.

    Now - perhaps your idea of "simple" and "complex" are different than mine, in either direction. But what I call "complex", like above, is a type of application that has always been common in IT (at least in brokerage and related fields it has). Now - please, pretty please, show me the simple solution that has eluded me on this one.

          -Mike
  12. Simplicity rules again[ Go to top ]

    There is an extremely fine line between Simplicity and Stupidity (via KISS). Unfortunately, nearly most of the engineers and architects I've worked with fall into the second category. They simply mistake Stupidity for Simplicity and think what is built is it. They neither go back to reanalyze what they've done for improveme it nor do they learn how to make their software manageable/configurable to the supporting infrastructure (to make IT life easier). IMO, Stupidity begets Complexity.

    I once was very fortunate to work with a engineering group that understood those differences really well. Later on, middle-management got rid of the group because those managers had inadvertently created another competing product.

    I'm still searching for another engineering group like that.
  13. Difficulty in achieving simplicity ...[ Go to top ]

    Hi,
    I read the article and Ward as usual put the point excellently. I have to say that it's really very difficult for lot of designers/architects to come up with simple designs which meet the requirements. There's a tendency on part of people that if they use all the features of <

    Ram
  14. Cunningham, Udell, and all those InfoWorld people strike me as being first rate professional bullshitters. You know, the guys who can talk for hours and not say anything. In some of my posts in other threads on this forum, I've voiced my convictions on keeping things as high level as possible. I really do think it's the most important thing in software, but these people are even beyond the high level -- they are at the vapid bs level.

    But they raise a crucial problem matter. Not that they offer much towards the solution, but the problem is important: Is it possible to bridge the gap between intention and implementation in an automated fashion?

    Java as a language holds most of the promise so far. It delegates the machine implementation to the VM. Similarly, maybe we can come up with a higher level VM, which will enable us to achieve the implementation of our business intentions. Such VM would read our intentions and translate them into a Java (J2EE) code.

    Not only is simplicity very important, stupidity is very important too. Anytime we end up with a piece of code that's intelligent, it gives me that uneasy feeling. Code that's too smart... I don't know. I don't trust that code! Now, a piece of code that's extremely stupid, that I can live with.

    What I mean by this is that a piece of code that's fancy-schmancy is prone to surprise us down the road. And such surprises are in most cases not pleasant ones. I'd much rather go with code that's dull and plain, but is easy to grasp and is obviously doing only what it's supposed to do, than with code that's oh so smart but who knows what it actually does (or is capable of doing).

    What we need is more stupid and simple code and more smart people to go with it, not the other way around. Corporations nowadays seem to go with trying to implement a lot of smart code and then hire legions of not so smart people who are supposed to work around the clock trying to maintain that code. This is not a very bright strategy, as it always seems to backfire. That's why I'd rather go with the simple and stupid implementation, and then get me some intelligent people to tweak it around a bit to make it do what we intend it to do.

    Some people say that simple code cannot do much, and cannot address the complex issues, but they are plain wrong. Simple code can be very powerful, *if* you know how to employ it wisely (which means the onus is on you to have the skills and the knowledge).

    Alex
  15. Cunningham, Udell, and all those InfoWorld people strike >>me as being first rate professional bullshitters. You


    I don't know about Udell but Cunningham ain't bullshitter. His contribution to OO is enormous and most of the things people take for granted (Design Patterns and Refactoring) ward had influence.
  16. <quote>
    Java as a language holds most of the promise so far. It delegates the machine implementation to the VM. Similarly, maybe we can come up with a higher level VM, which will enable us to achieve the implementation of our business intentions. Such VM would read our intentions and translate them into a Java (J2EE) code.
    </quote>

    I've seen you argue for this before (at least, I think it was you).

    No, I don't think we can come up with such a higher level VM. Real domains are very, very complex. What a JVM does is not complex, in that the rules that stack machines follow are well-explored and extremely well-known. A decent comp sci grad student should be able to write up a set of requirements for a virtual machine (a decent grad student writing 10 years ago wouldn't have done as good a job as the Java team - but they could have done something workable). Yet I can't imagine who would have the skills to write up the requirements for your 'enterprise VM'.

    Don't try to build a framework to solve all future problems related to your domain, because you can not predict all future problems. Solve the problems that you have in a simple way, so that you can simply extend or adapt later. Attempts to build 'one size fits all universally flexible yet easy to use' frameworks usually result in horribly complex code that isn't flexible enough. That, I think, is Ward's point.

    It's also the moral you get from reading work on AI by people like Doug Hofstadter on AI: the real world is really, really complicated. Really.

    Sean
  17. Don't try to build a framework to solve all future

    >problems related to your domain, because you can not
    >predict all future problems. Solve the problems that you
    >have in a simple way, so that you can simply extend or
    >adapt later. Attempts to build 'one size fits all
    >universally flexible yet easy to use' frameworks usually
    >result in horribly complex code that isn't flexible enough.

    I think the above is wrong-headed, even if it sounds seductively simple.

    Let's examine the situation: if we take a typical business application code and scrutinize it carefully, we'll notice that the large portion of that code has absolutely nothing to do with the business domain. I'm talking about the code that deals with administrative stuff (configuration etc.), as well as the code that wrestles with the underlying mechanical platform.

    Furthermore, if we take two or more business applications covering totally different business problem domains, and examine their respective source code, we'll notice that all of them tend to share a very large base of almost identical code. This is the phenomenon that people call 'reinventing the wheel'.

    Knowing the above, we can conclude that a) separation of concerns is the most important aspect of software development, and b) once those concerns are separated, we can try to automate their implementation.

    This is what today's frameworks are actually attempting to achieve (although all of them are obviously still in their early infancy). Separate the code that changes from the code that stays the same. Factor out the code that stays the same, solidify it in a framework, and provide the hooks where one can plug in the code that changes.

    Now, typically the code that changes is related to the requirements of the business problem domain (this holds true in 99% of the cases). What I was trying to say is that we should focus our efforts on building an enterprise virtual machine (EVM?) which will enable us to forget about implementing the code that always stays the same anyway. That would liberate us to dedicate all our time and energy to solving the problem domain where the code keeps changing, because, as you say, we 'cannot predict all future problems'.

    Of course, there will be people who will complain, saying that such solution is worthless, because it doesn't solve 100% of the problems. But that's just sheer laziness, if you ask me, so I'm not going to addres such complaints. In any event, something is better than nothing.

    Now, as far as the 'solve the problems that you have in a simple way' dictum that stems from the XP dogma, I'm afraid it's all wash. We simply cannot do such things in a wishy-washy way, hoping for the best. It's a big fallacy, and the one that trylu gives a black eye to the XP credibility.

    Whatever we do when designing our solutions, we must approach it in a defensive way. We must do everything possible to shield ourselves from the impact of future disruptions (because they will happen, whether we can envision them or not). XP's simplistic 'just make it work, don't worry about making it right' modus operandi amounts to a very suicidal approach. I can see how nomadic developers (the ones hopping from project to project) would find it acceptable, but anything longer term requires a more mature approach.

    Yes, we cannot predict future problems, but that doesn't automatically mean that we are free to stick our heads in the sand.

    Simplicity is the most time-honored way to approach this problem defensivelly.

    Alex
  18. Re: Refactoring the business[ Go to top ]

    Alex, I like your point of view. I have read similar points from you in the past. I agree that there is similarities between different business domains. However, I think that an EVM will be very difficult to achieve, even very improbable. Understanding an number of domains, to even understand the requirements for such a product would in itself be difficult and timeconsuming, let alone writing the specs for the EVM.

    On a second note, I must point out that everything today has complexities. Taking Alex's TV analog. To initially operate a TV one must tune in the channels. Doing this requires at least some understanding of the fact that each channel uses a different frequency and the TV tunes into that channel in order for you to see the signal (picture and sound). Initially, TVs generally have poor image (from the multiples of TVs I've setup) because they have low brightness and high colour. Changing this settings requires knowledge of lighting.

    I would say TVs seem simple. They are common and are used on an every day basis. But even since doing Graphical User Interface design subject at uni, I realise that it is not. Even the operation of a door and light. If you were to get a primitive man and put him in front of the door. What would he do?
  19. Re: Refactoring the business[ Go to top ]

    Sorry about the spelling mistakes. I really should double check my posts.
  20. Re: Refactoring the business[ Go to top ]

    On a second note, I must point out that everything today has complexities.


    You are, of course, right. It is true that products such as TV sets, cell phones, cars etc. are quite complicated to operate. However, and this is the key point, it would be very easy to make them much, much more complicated to operate. Even doing a very simple thing, such as opening a bedroom door, could be engineered so that you'd need a five day course before you'd be able to use it.

    People are ingenious, and most of us (especially the engineering kind) are capable of creating unbelievably complicated things. And we take pride in doing that.

    Now, for some reason, we choose not to make using a cell phone or a TV set overly complicated. It's simply the matter of practicality, I guess. Common sense kicks in, and overrules our need for being proud of accomplishing extremely complicated things. But for some strange reason, we choose not to strive for the same practicality when it comes to building software product. With software, everything seems fair game. People do need five day courses before they are able to operate trivial software products. That's what I'm complaining about. If I don't need a five day course before I can use my phone (which is a fairly complex piece of machinery in itself), how come I need a five day course before I could use a software product (such as Eclipse, for example)?

    >However, I think that an EVM will be very difficult to achieve, even very
    >improbable. Understanding an number of domains, to even understand the
    >requirements for such a product would in itself be difficult and
    >timeconsuming, let alone writing the specs for the EVM.

    Well, believe it or not, it had been attempted. I don't know if any of you have heard of IBM's "San Francisco" project (San Francisco Shareable Frameworks)? It was instigated some 7- 8 years ago, and had since then been disbanded. The project was aiming at delivering an enterprise-wide virtual machine (it was supposed to come with a lot of the knowledge pertaining to the run of the mill business operations, same as JVM comes bundles with the knowledge of the run of the mill computing platform operations). Large portions of that project's specs were ported to J2EE platform (only the plumbing related portions, though).

    So, although it initially failed, such projects will resurface, sooner or later. Eventually, I'm convinced we will have some sort of partially fledged EVM available to us. It takes time, but it's unstoppable.

    Alex