August 18, 2005 - Joel (Still) Doesn't Know XP
I love reading Joel On Software. He's a smart guy with lots of good ideas, which makes it all the more frustrating when he's wrong about something. The topic on which he is mostly likely to be wrong is XP, but that isn't too surprising as he's never actually done it, which makes it a bit like criticising someone using the Penhold-Style grip when you've only ever used the Shakehands-Style. You might be a very fine table tennis player, but you've now entered the realm of speaking out of your... ignorance. And that's about how it sounded in Joel's recent article on The Project Aardvark Spec...
The (for me) problem section of Joel's article is when he's talking about his success in simplifying the software after running into problems when designing some of the screens:
Many times, thinking things out in advance saved us serious development headaches later on. When I wrote the first draft of this spec, I had a more complicated flowchart that assumed that either party (helper or victim) could initiate the process. This became extremely complicated and convoluted for various reasons. As I worked through the screens that would be needed to allow either party to initiate the process, I realized that Aardvark would be just as useful, and radically simpler, if the helper was required to start the whole process. Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule. I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that.
The problem here isn't with Joel mocking up his screens, it is with his strawman of the "XP fanatics". On a sudden hunch I checked out Kent Beck's Extreme Programming Explained and found the section on "Role of Pictures in Design":
First, there is nothing wrong with designing software using explicit pictures instead of a purely mental or textual model of the system, and there is much to be said for a graphical approach. Trouble drawing the pictures can give you subtle clues about the health of a design. If you find it impossible to reduce the number of elements in the picture to manageable levels; if there is an obvious asymmetry; if there are many more lines than there are boxes. All of these are clues to a bad design that become evident from a graphical representation of the design. Another strength of designing with pictures is speed. In the time it would take you to code one design, you can compare and contrast three designs using pictures.
Hmmm... so apparently not all XP people are fanatics, so why does it feel like Joel is trying to tar all of us with the same brush? My personal feeling is that Joel will keep getting XP wrong till he tries it himself, and I can't be any clearer than that.
Posted by Jeffrey Fredrick at August 18, 2005 03:22 PM
Trackback Pings
TrackBack URL for this entry:
Comments
The main problem I had is that Joel didn't follow through on what an XP team would have done. Consider this:
Story 1: Helper initiates process.
Story 2: Victim initiates process.
Developers estimate, for a little bit, and they come up with an amount of time for each (say, 10 days each, to keep it large). Customer says that Story 1 is more valuable, they go off and do it.
Story 2 is then scheduled, and the developers start it. They realise that the interactions make it a lot more complex than initially expected, they raise that with the customer. The customer says "Well, this story isn't really that valuable if we've already got the other story in... we don't _really_ need both. Let's kill this one now". Elapsed time: not much.
Posted by: Robert Watkins on August 18, 2005 04:44 PM
I fully agree with Robert.
And now, if someone wonders why there are two stories - imagine we had just one, "initiate process".
According to Joel, that would have been a very complex story - I imagine one that the team would have had problems with estimating, and perhaps even one that doesn't fit into one iteration. So the team would have been *forced* by the "rules" of XP to split it into substories. The stories presented by Robert look like a natural split - especially if you consider that the customer might indicate *up front* that they have different business value.
So assuming that an XP team doesn't analyze these things up front simply is a straw man argument.
Posted by: Ilja Preuss on August 19, 2005 03:43 AM
As an aside, you usually don't schedule 10 day stories in XP. You max at 1 or 2 days...
Posted by: Amir Kolsky on August 25, 2005 08:00 AM
When I started writing the blog I was intending to say that an XP team would have solved this problem equally well, and the example Robert gave was almost exactly what I had in mind, so completely agree on that point. But when I came up with that quote from Mr. Beck I just had to go with that...
Posted by:
Jeffrey Fredrick ![[TypeKey Profile Page]](../../nav-commenters.gif)
on August 25, 2005 08:39 AM
Customer interaction/involvement is one of the key factors in XP. It is easy to have customer on board if we are developing a custom solution. But when we develop general purpose software for everyone, like Agitator, how do we effectively involve customers in the development process? Company like Agitar has a wide range of customers and they may have their-own priorities, right? I am definitely not an XP expert, so I could be wrong... But would like to hear comments those of you, how have more experience and expertise...
Posted by: Chidambaram Danus on September 20, 2005 02:36 AM
At Agitar it is the product manager that plays the role of customer. The product manager sythesizes input from our field people and customers, and we augment that by developing personas as described in Alan Cooper's _The Inmates Are Running the Asylum_.
Of course it is also tremendously helpful that we are creating tools for developers and the managers of developers, so it makes it much easier for all of us to see things from the "customer" perspective.
Posted by:
Jeffrey Fredrick on September 20, 2005 10:28 AM
Post a comment
W3C link checker Powered by Movable Type 3.16
This weblog is licensed under a Creative Commons License.
Agitar, Agitator, Software Agitation, Open Quality, and Quality Level Agreement are trademarks of Agitar Software, Inc.