ExtremeIconoclasm sounds more like extreme partisanship to me....
Which part?
Step 1: Observe that their thing (eg Rose or welfare or the military) and your thing (eg XP or small government or disarmament) don't mix well.
Step 2: Declare their thing "a modern-day icon" (implicitly, a Bad Thing).
Step 3: Make the implicit badness explicit by declaring that their thing implies a "soul-destroying belief system."
Step 4: Wrap yourself in a mantle of virtue (as, for example, by taking the role of religious reformer).
Step 5: Declare them "the enemy" and allow no compromise. -- TomKreitzberg
Rose and XP don't mix well - agreed. Are you conceding that by the way?
But that's not all that I have observed since Case tools first appeared around 1985, with 'object diagrams' bolted on soon after. I was an independent consultant at that time to some large companies in the UK. What I observed - and many independent studies were confirming when I last cared enough to look in the early 90s - was that selection and use of these tools often coincided with very little of business value being achieved in projects.
To give an example from a client in 1985 (earlier is easier not least because it's less likely to give legal problems):
But the whole point of the religious icon analogy is that I do not believe that the use of Case tools logically necessitates failure or even under-performance. If there is a connection (apart from terrifically bad luck) I'm arguing that it must have something to do with a very damaging belief system that somehow comes with the tool, something close to what Wiki calls BigDesignUpFront.
Perhaps the kind of stupidity I report from 1985 never goes on these days. In fact I'd accept that most organizations have learnt a good deal more about what does and doesn't work in software development since then. And it just so happens that in my humble view most of what has been usefully learnt (although not all) is currently showing up in ExtremeProgramming.
Now what I would love to be able to read are some case studies for Rose (which must surely be a better and more practical tool than any preceding it) that show that ExtremeIconoclasm, if practised indiscriminately across the whole of the planet in the past, would have prevented a system of terrific value from being delivered.
You know, the "Congratulations, you just aborted Beethoven" kind of punchline.
-- RichardDrake
So what does "extreme iconoclasm" mean? The impression the ExtremeIconoclasm page gave me is that it is "the attacking or overthrow of the whole Case and UML 'mythology,' in particular RationalRose." I stand by my characterization of this as partisanship.
From the above I infer that you mean something closer to "the attacking or overthrow of BigDesignUpFront (BDUF)." If this is correct, then I'd suggest first, that BDUF be mentioned sooner and with more emphasis on the ExtremeIconoclasm page; and second, that the XP community has hardly been reluctant to make ExtremeStatements against BDUF. This leaves me wondering what the value of adding "extreme iconoclasm" to the XP namespace is.
Frankly, I find the ExtremeIconoclasm page as it stands an ill-conceived muddle of history, religion, and software design methodology. I think the weaknesses of the analogy of MethodologistAsReligiousReformer are so obvious and pervasive that I'm surprised anyone would care to adopt it. -- TomKreitzberg
Tom, something in what I have written has obviously ticked you off. Sorry if I didn't communicate clearly enough. Perhaps the key word for you to re-read is "tentative" in my very first sentence. Nonetheless I did intend:
Of course I'm not alone in my desire to improve things and to be as radical as we need to be to do it (but no more radical). There are plenty of other great names in the Wiki namespace and fresh analogies that can help guide us. Sorry if this one didn't work for you.
I came up with an analogy which is about two rival groups of religious folk battling it out for dominance. This happened in history, like it or not. I wasn't so stupid as to think that this analogy has enormous selling power with an increasingly secular culture. I just thought that it was very apt (although limited like all analogies). And when it comes down to it I am saying that I am thoroughly for LowCeremonyMethods like XP against the bureaucracy, ego and downright oppression that too often seems to come in with the likes of UML/Rose/RUP.
Rather than get worked up about the nature of the analogy, do you have any evidence in the form of case studies supporting Rose as I asked above?
-- RichardDrake
Well, let's look at your analogy: ExtremeProgramming's paradigm : BigDesignUpFront's soul-destroying belief system :: Lutheranism : Catholicism. Can you think of something other than an increasingly secular culture that might reduce this analogy's selling power? (Beyond that, Luther's Reformation had nothing to do with Iconoclasm in the religious sense and very little to do with iconoclasm in the general sense; it overthrew one order to replace it with another.)
But I'm still unclear about exactly which are the "false attitudes and beliefs about software" that need to be smashed. BigDesignUpFront is one, yes. How about Rose? All forms of CASE tools? UML? And are these extreme proscriptions universal, or just for XP projects?
Since I still don't know what you mean by ExtremeIconoclasm, I can't point you to case studies showing it's a bad thing. (I assume you're unpersuaded by the two dozen "case studies" at Rational's website.)
-- TomKreitzberg, still mulling over the idea of extreme tentativeness
It's tentative iconoclasm that's really hard to master, I can tell you!
ExtremeIconoclasm simply wasn't about XP : BigDesignUpFront (BDUF) :: Lutheranism : Catholicism. What I was mainly exploring was Rose : BDUF :: icon : belief system.
See ReformationAnalogy for the other stuff (and remember that nobody is forcing anyone to click on that wiki name, which I've only created because of this discussion).
Then the key ingredient was the belief of an iconoclast of any ideology (think Maoist if it helps): that it is necessary (for some unknown reason) to destroy the icon to rid people of the associated belief system. From my twenty year but still very limited commercial development experience, and triggered by the clarity with which Kent answered the question about Rose at OT99, I suspect that the same is often true for Rose : BDUF. Better education from the likes of Beck will surely help and will then I guess reduce the need for iconoclasm or the icons themselves. And so the TentativeIconoclast? makes his way into the ExtremeOxymoron hall of fame.
I'm least happy in fact with identifying "harmful belief system(s)" solely with DBUF as discussed on Wiki. I preferred ExtremeHumility as the antidote the moment I saw that WikiName. In fact I still see dangers of XP itself oversimplifying and becoming proud and 'religious' in some quarters. Anyone willing to join me in ExtremeBeginners?. But the low ceremony aspirations have gone really deep, Wiki debate has been the best debugger for any new method yet seen (apart from using it in real projects) and I expect XP to avoid anything like the same level of problem seen in the past.
As for the Rose case study, all I want is for someone on Wiki to tell us: "This project would have been sunk if we hadn't used Rose". So that we can question them about it.
It's called the ExtremeInquisition?.
Only joking
-- RichardDrake
I freely admit to being an *******, but I don't get this iconoclasm thread at all. We're not out to destroy anything, we're here to offer something light and airy and freeing, something gentle and sweet and delicious.
You do have to think about what you mix with XP, however. You can bludgeon with a mace or fence with a foil. But you can't fence with a foil that has a mace tied to the end of it. A chunk of heavy methodology put into an otherwise lightweight environment can overbalance the scale you are trying to use to guide the project.
Rose is a fine product to use to explore objects. I've used it and liked it. It should be used in conjunction with a projector to show the pics on the wall while you group design. It's just great for those cases where you can't get permission to buy some 4x8 cards. You just shouldn't use it for more than a half-hour before you get down to coding something. And don't hook up the printer.
And an end-to-end graphical tool might be just as effective for XP as is Smalltalk. But you have to be able to do everything in it, and quickly. I don't know of a tool like that, but it might be out there. -- RonJeffries
Ron, would what you've just expressed ever lead you to recommend that a project purchases Rose, if it hasn't already? -- RichardDrake
I never say never, but I can't imagine the situation. Unless they were rabid tree-huggers and opposed to cards, maybe. ;-> -- rj
That answer is iconoclastic enough for me. Thanks. -- rd
Thanks for that answer. I see that I misread the question as "recommend that an XP project purchase Rose", which I likely wouldn't. Larger projects that cannot use XP and that have a need to design a complex system and to communicate that design should definitely consider Rose. It was a very promising tool when last I used it, and I have heard that it is better now. -- rj
This must be Ron in a 'genteel' mood. -ac
There was a bit of deliberate circularity built into my question too. How many "larger projects" are likely to ask RonJeffries for his recommendations?!
How many wise large projects are there? (thanks for the new ExtremeOxymoron)
More interesting again, Ron and all OfficialXpPersonnel: what proportion of current projects do you think "cannot use XP" and what should this proportion become over the next few years?
I don't know enough about the proportion of projects of various sizes, criticality and such to answer the question. I've never been involved with a project that couldn't have benefited had I done more things like XP. Testing, presence of a real customer, etc etc. Documenting only what is really needed, writing clear code as the prime directive.
More interesting, but still impossible to answer without data I don't have is what proportion of projects can't be as lightweight as XP? AlistairCockburn begins to speak in his work to the relationship between project variables of size and criticality, and the size of the methodology required - but does anyone know the breakdown of projects into his matrix? I certainly don't, and can't answer the question without that data. -- rj
This was exactly the kind of question that I wanted to come out of a discussion of ExtremeIconoclasm, honest. The ecumenical side-issues were another of those little Wiki detours I guess. -- RichardDrake
You could try to find a question that Ron could answer without being cynical, sarcastic, or iconoclastic. That might take you a similarly long discussion, I suspect (try asking him something simple, such as his age, for instance). -- ac
I feel that's not quite fair. How could anyone know what proportion of projects have any given property? I changed my answer above since apparently folks feel I've been too cynical in pointing out that the question can't be answered as asked without data that I certainly don't have.
Ron, I thought your original answer was great. I hope you get that job as coach in Hawaii or wherever. Everyone knows that nobody knows, not even ac, exactly how many projects would benefit from XP right now. It depends on people's decisions - not rational ones! I believe that it's going to be enough for fame and hopefully fortune in your case. -- rd
I don't understand this page and its parent, and I never have. XP does not attack cherished beliefs, it offers beliefs of its own, based on observation of what works and what doesn't, expressed as clearly as we can, and bounded as clearly as we can as to where and when it might apply. Reasoned questions get reasoned answers, as best as I'm able. -- rj
Let me try again. My practical observation (or firm belief, depending on your point of view) is that many projects would benefit from the removal (or strict non-use) of Rose and similar tools, preferably at the start but possibly later in a project. Anyone with any sense knows that having these tools around doesn't logically necessitate bad practice. Plus there are a lot of emotions and cherished beliefs involved. That's why I felt that the religious icon analogy might shed light and was worth presenting (tentatively). What did the reaction prove? That there are a lot of emotions and cherished beliefs involved!
Let me try the FreeBoozeAnalogy as another way of attacking this. It was designed to be more amusing than ExtremeIconoclasm but provoke thought about the same issue from another direction. Anyone should feel free to edit or remove aspects that they do not find amusing. Sincere apologies to all in advance.
If I'm not part of XP in expressing my view on the need to remove tools that often seem to lead to bad practice, so be it. Hopefully I'm still part of Wiki. -- rd
No judgment made here on whether anyone is part of XP except that I judge myself to be. (Some may disagree.) It seems to me that rather than smashing icons, one is more effective by coming out in favor of something rather than against. "I find CRC cards to be more tangible, more flexible, and easier for normal humans to understand, and so I prefer them to machine-based tools. I'd recommend you start with the simple approaches, and move to more complex ones only if you need to", rather than "Get that ******* Rose out of here, you ****** ********", which might be more what I really think - or might not. -- rj
At the risk of interposing myself between two people in a public dialog, I have to say that I agree with Ron. It seems to me that Richard, you set up a straw man in ExtremeIconoclasm, and then baited Ron into a dialog that you then claimed served your point. In ExtremeIconoclasm, you yourself said, "I would probably have been tougher than Kent in the way I answered. What Kent in fact said: "There's no reason at all in theory that you can't use RationalRose and be extreme. However ...' "
In other words, Kent replied mildly, quite out of keeping with your definitions in ExtremeIconoclasm (the same again you say about his book). You then projected your wish for ExtremeIconoclasm onto his answer and Ron's.
Rubbish I'm not that clever
One of Kent's standard answers to suggestions he disagrees with is, "Well, you must be smarter than me, because I can't figure out how to do that." That is quite the opposite of ExtremeIconoclasm. Ron's pet answer is, "Do you have some data for that?" Again, quite the opposite technique from ExtremeIconoclasm.
The only ExtremeIconoclasm I'm interested in is removing icons from projects where they are doing damage, not ranting about them on Wiki. I have the impression that Ron and Kent are very good at this (removing not ranting!) but that they may not want to admit it. That's fine.
While I find the salesman's techniques running strong in XP, that is fairly natural, if annoying. To create space in someone's mind for a specific idea, you need to shift the other ideas to the side - this can be done in various ways, and Kent and Ron's strongest phrasing tends to be, "Why would I want to do that?" In other words, they stress what they themselves would do, or have seen, instead of insulting people's beliefs directly.
I have not seen them attack Rose or UML, and scarcely more than indirectly. "You could possibly use it. When I saw it tried, it failed. I suppose you might be smarter than me, and you can figure out how to make it work." None of this matches the direct attack techniques you describe on this or the parent page.
So now I'm curious as to what your agenda is (besides ridding the world of Rose). -- AlistairCockburn
I don't believe you've characterized my motives at all correctly Alistair.
It is simply not my goal to rid the world of Rose.
The key belief lying behind ExtremeIconoclasm and the FreeBoozeAnalogy is that, from experience of just 20 years, all projects and project teams I have ever been near to or part of fall into the trap of over-modelling and over-planning on paper (including case tool) and over-modelling in code (ahead of the next known requirement). All that I've ever achieved is to reduce the problem - in some cases leading to striking business success. But at the end of every project I've always been aware that we hadn't been incremental enough, we could have broken the process into yet smaller steps, to the great benefit of the end result. That's in every project I've ever been involved in. It leaves a kind of scar.
I believe that this is a major problem in the way that we've been taught to think about and do software. I believe that it may go deeper than that as the human psyche and our social structures face the very great potential (including money making potential) of turing/von neumann machines based on ever smaller silicon. That's why I go back to ExtremeHumility and a few analogies, it's all I've got in the face of this. I don't have no theories.
I agree with what you say about the sales techniques used by Ron and Kent and I believe that at one level I was asking whether Kent was marketing XP most effectively by what he said in reply to the question at OT99. But of course that's up to him. In terms of early consultancy influences, I'm a TomGilb man and Kent's a GeraldWeinberg one. Those two wrote books together but they're two very different people. Again, if you can find some theories on that great.
Anything that helps reduce the over-modelling problem for me is in, everything that doesn't is out. XP, taken as a whole, is the most positive influence to arise that begins to address large parts of the problem. Your and Ron's comments convince me that more from me in this thread isn't going to help. Rose I'll leave to wiser heads.
See ModelingTrap.
-- RichardDrake