(Update: Please take a look at last Tuesday's JE before responding to this one...)
I must admit, I've always had a simple approach to programming. It usually goes something like rough design -> documentation -> code -> test -> deploy, and then update documentation if there's time. The company I work for is getting hooked on a lot of, what I consider to be, fads, and it's getting annoying, as this kind of thing tends to get in the way rather than resulting in better code. Sometimes I see the logic, I just don't think there's time. Other times, I think someone needs being hit over the head with a bat.
Most of us, I guess, who've been in this industry a long time, have noticed technologies being promoted that discredit themselves, frequently without actually destroying themselves. For example, Object Orientation has always struck me as a fundamentally good idea. However, it's used for EVERYTHING, and it's not, actually, all that good at "everything". The bizarrest was seeing it "leveraged" (and I used that term with deliberate contempt, because OO was being used as much for buzzword compliance, as OO) for building websites. For the most part, websites have their own paradigm. OO isn't it, or at least, is no more it than any other back-end storage model - and trust me, you're going to have to use multiple back-end storage models - and the attempts to "automate" programming such systems lead to such horrors as binaries encoded in the middle of
So for the last year or so, my employer decided that "Extreme Programming" was becoming the in-thing, and that's what we need to do. It's the latest fad, built on top of a whole raft of trendy techniques. About 75% of the programmers were sent on XP courses. We expected to learn about programming. Instead, the entire courses were oriented around "trust" and "teamwork". I kid you not, but in one seminar, we had to walk from one side of the room to the other, blind folded, with a beanbag on our heads. If it dropped, the rest of the programmers were supposed to yell "Idiot! Idiot! Pick it up! You're letting down the whole team!" while the poor bastard fumbled for it on the floor. On another, a bag was put over the head of one candidate, who then had to run towards a wall. "The Team" was supposed to stand in the way with linked arms to prevent the individual from actually crashing into the wall. It was about trust or something.
So the latest project I've been assigned to was managed entirely according to "Extreme Programming" techniques. The first meeting seemed reasonable enough, one of our marketing people came in with the project requirements. We extracted the spec from him, essentially, in the manner of an interrogation. Each programmer was required to ask five questions, then hand over to the next programmer, until all programmers had no more to ask. The salesperson confided in me afterwards that he was considering resigning if that was going to be the usual way of dealing with specs in future - he said he understood the need for them, that programming rarely gets decent ones, etc, but that this was just hostile.
We then had a design meeting. Most of us thought this would be straightforward, and two or three people actually came with papers with block diagrams and other stuff they'd thought of in terms of how the system could work. The project manager allowed each of them to speak, and then had them each stand in a corner facing the wall, while he hurled abuse. "Rule #2 of Extreme", he told us, "Your design is wrong. Don't fucking even try. Code, fuckers, code"
Most of us chuckled nervously, not actually knowing if he was serious. Then he appointed me, and a collegue called Stuart, to work on the central database. "Your job is to put together the database. It's going to be simple. Don't put any bullshit in, you write what's needed today, now, and nothing more. You go it? Do it now"
Stuart and I looked at each other, and the manager then stood up. "Right now fuckers. Get up, code. Here", throwing whiteboard markers at both of us and pointing at the board. We got up and went to the whiteboard. I wasn't sure what to do, so I began by drawing the usual cylinder that represents a database"
"WRONG SHITFACE!" screamed the Project Manager. "What the fuck are you doing?"
"You said the database...?" I stammered. "I said NO BULLSHIT! You write what's NEEDED TODAY. DID YOU NOT HEAR? ARE YOU A RETARD?" I wasn't sure how to answer, "We don't NEED a database yet because NOTHING ELSE HAS BEEN PROGRAMMED. You do the MINIMUM POSSIBLE"
"But, we'll need a database..."
"Yes, we'll NEED ONE. Not we NEED ONE. We WILL NEED ONE. That's a FUTURE REQUIREMENT"
And so on and so forth. Anyway, we ended up with a team of about fifty programmers on this, with meetings twice a day about current statuses. The team was divided into pairs. One programmer programmed. The other's job was to look for mistakes, and then yell at the first for making the error. If the error was severe enough, he would announce it on the loudspeaker. What constituted an error was never clearly defined. Sometimes it was a logic error, or a typo, but other times it was allowing code to be too flexible and too open for future expansion, even when that was the best way to write something anyway. I got in trouble for writing a FOR loop with a named constant as one of the limits. "Named constants", it was explained to me, "mean you're looking at solving tomorrow's problems, not today's. Your code just needs to work for today. If the program can only support 100 simultaneous connections, write 100, not MAX_CONNECTIONS"
At the end of the day, it's not a way I'd like to program, but you can't complain about the results. The software is completely solid. Nobody's come across a single bug, it's a little slow, but it's not bad.
In that respect, Extreme Programming seems a great idea.