In the course of our interviews at the PASS Summit 2009 this month, we managed to snag four top-level SQL authors and educators at once, in the same room. (Actually, in the same 8'x8' space, but who's counting.)
In Part 2 of our series "Buck, Paul, Joe, and Louis", we have an absolutely wonderful talk about agile development with Paul Nielsen, Joe Celko, and Louis Davidson (right before Buck Woody joined the party). Louis started it out, talking about managers being the real problem, because they "want it done immediately, they don't want it designed first." This is one of my favorite topics, so I was absolutely thrilled to be in agreement with so many SQL development gurus.
Here's a (nearly word for word) transcript of the talk that followed:
Jen: "In a gig I was at recently, they got the business requirements, they handed it to the coders, and it was sort of "design as you write it". Which seems like a BAD idea to me."
Paul: "And because they don't do design – they THINK they're doing rapid development, rapid development tools, agile – but because they don't do design it actually takes them longer to develop, they don't have extensibility, they don't have data integrity, and they have to redo it again sooner."
Joe: "Agile is usually an excuse to do what we used to call 'cowboy coding'. There's a book on the first agile project – Chrysler. It was a year 2000 thing. It failed. Chrysler eventually had to throw the whole damn thing out and redo their payroll package in COBOL, from scratch. Agile's based on a failed project, and it's become an excuse. Yeah, it's gradually developing into something that's got some merit, but, 'I'm not sloppy, I'm agile!'"
Louis: "The point I was making about playing chess [really quickly] is, people who do agile seem to play one move ahead. And to do it really right, you need to be playing ten moves ahead. Obviously the idea behind doing monthly iterations and having some shippable code is awesome, but if you don't know what's coming up down the road, you may do something really horrible here, and then down here you gotta redo it."
Jen: "And it's driven by this panic to give the users exactly what they're asking for at that moment, as opposed to what they really need and taking the time to go, 'You know that's a GREAT idea, but we should really consider doing it this way because…"
Paul: "There is some truth in there. The whole idea of, let's spend a whole year gathering requirements, specify it out…"
At this point (about 4:45 in the video) Buck shows up, and we continue the talk. It's well worth going to see the video for a number of reasons, but certainly to catch the tail end of our talk on agile development. I'm inspired, so watch this space for more on the failings of "rapid development".
In the meantime, I'd love to hear your stories on failed or successful agile or rapid development projects. Comment, tweet, or email me.
-Jen McCown, http://www.MidnightDBA.com