Emperor s New Code (a Story)


Once upon a time there lived a project manager (named, curiously enough, Fred Emperor) whose only worry in life was to keep up with the latest trends in development techniques. He changed methodology almost every project and loved to show off his knowledge to management.

Word of Emperor s habits spread over his department and beyond into Internet newsgroups. Two gurus who had heard of the project manager s fashion consciousness decided to take advantage of it. They introduced themselves via e-mail with a scheme in mind.

We are a pair of very good programmers, and after many years of research we have invented an extraordinary development process of such agility that the cost of changing requirements has been reduced nearly to zero. As a matter of fact, we have flattened out the famous cost-to-fix-defect exponential curve that Barry Boehm presented in Software Engineering Economics ! they wrote.

One of Emperor s programmers heard the gurus strange story and notified Emperor, whose curiosity got the better of him. He decided to see the two scoundrels.

Besides reducing the cost of changing requirements, sir, we ve eliminated the need for up-front design (this is such a silly concept with our new method that we call it BDUF, short for ˜Big Design Up Front ) and, of course, your programmers will never have to waste any time documenting their work, for all the code is self-documenting . One important thing, though: You must be aware that closed-minded people on your staff might tell you that this approach can t possibly work. Always remember that this is a sure sign that these people are afraid, and do not take these fearful opinions seriously. In fact, you d be better off getting rid of these cowards, the two gurus informed Emperor.

Emperor gave the two men a contract to build a payroll system in exchange for their promise to begin working on the project immediately. Tell us what you need to get started and we ll give it to you. Just remember, the payroll system must be done in 4 years before our mainframes drop dead, said Emperor.

The two gurus asked for a big room with lots of computers running Smalltalk and a large stack of index cards, and then began working. They also asked for a full-time customer, who they called a goal donor, to live in the room with the Smalltalk programmers. The project manager looked around and, finding all of his key employees busy, he grabbed the first person he could find hanging around near the coffee machine and tossed him in the room with the programmers.

Emperor thought he had spent his money quite well ”in addition to getting a new project completed that he could feel forever free to change the requirements of at any time, he would discover which of his programmers could churn out the most code in the shortest time, and which of his programmers were cowardly dogs, so he could get rid of them. A few days later, he called the old and wise chief technical officer (CTO), who was considered by everyone to be a man with common sense. Go and see how the work is proceeding, Emperor told the CTO, and come back to let me know.

The CTO was welcomed by the two gurus. We ve built and tested the system 17 times since Tuesday, they said. We re almost finished, but we need a few more cases of Pepsi, more computers to run our regression test suites on, some chocolate-chip cookies (coding is hungry work, indeed), and special desks with two chairs, for we always program in pairs to compensate for not doing any up-front design. We ve made extra certain to turn a blind eye toward future requirements and only to build what we need today. Here, Excellency! Admire the test scores ”feel the agility of the process!

The CTO bent over the stack of index cards and tried to see the architecture that was not there. He felt cold sweat on his forehead.

I can t see any architecture, he thought. If I see nothing, that means I m stupid! Or worse , incompetent! If the CTO admitted that he didn t see anything, Emperor might claim he was incompetent and try to take his job.

What a marvelous architecture, he said. I ll certainly tell Mr. Emperor. The two gurus rubbed their hands gleefully. They had almost made it. More Pepsi, 18 bags of potato chips, and a couple of ping-pong tables were requested to finish the work.

Finally, Emperor received the announcement that the two gurus had the payroll system up and running. They came to Emperor s office to demonstrate it for him.

Come in, said Emperor. Even as they bowed, the two gurus pretended that their system, which had been designed to DoTheSimplestThingThatCouldPossiblyWork and could thus only pay a small percentage of the employees, would scale to handle all of the requirements.

Here it is, Mr. Emperor, the result of our labor, the gurus said. We have worked night and day (well, actually we knock off at 5:00 PM every day because we want to stay fresh) but, at last, the most agile process in the world is ready for you. Smell the code and experience how fine it is.

Of course, Emperor did not smell anything except a faint odor of bubble gum and Scotch tape, and he could not see any architecture between his fingers. He panicked and felt like fainting. Luckily, his chair was right behind him, so he sat down. But when he realized that no one could know that he did not see the architecture, he felt better. Nobody could find out he was stupid and incompetent. And Emperor didn t know that everybody else around him thought and did the very same thing.

The farce continued as the two gurus had foreseen it. Mr. Emperor, you ll have to give us an open -ended variable-scope contract in order for us to complete the payroll system, the two gurus said. Our new process doesn t operate well with fixed schedules or budgets ”fixed schedules give the code a funny smell. Emperor was annoyed, as he usually only used fixed-price contracts, but because none of his bystanders seemed upset, he felt relieved.

Yes, this is a beautiful process and it feels very agile to me, Emperor said, trying to look comfortable. You ve done a fine job.

The two gurus immediately started approaching publishing companies about getting book contracts to popularize their new process.

Mr. Emperor, they said, we have a request for you. The people have found out about this extraordinary process and they are anxious to learn more about it. Might we have permission to publish a dozen or so books about our process that reference the work we ve done for you? Emperor was doubtful about showing the details of his project to the people, but then he abandoned his fears. After all, no one would know about it except the ignorant and the incompetent.

All right, he said. I will grant the people this privilege. Book contracts were signed, magazine articles were written, and user conferences were scheduled in Italy. The gurus process was given great credibility based on the claims of success on Emperor s project. Magazine editors and conference coordinators anxiously scrutinized the ideas of the programmers across the industry. Everyone wanted to know how stupid or incompetent his or her neighbor was but, as the details of Emperor s project were revealed, a strange murmur rose from the crowd .

Alas, the goal donor whom Emperor had found by the coffee machine turned out to be a new hire, right out of school, who really didn t understand the requirements of the payroll system and completely missed the point that the mainframes were going to die in 4 years time. Encouraged by the gurus that changing requirements was no problem due to the variable-scope contract they had received, the project continued to consume soda, chips, and cookies for several years while they were refactoring code, without actually progressing toward completion. The two gurus assured the goal donor that this was no problem, because SoftwareIsNeverDone. And ultimately Emperor had to cancel the project, unfinished , which he did as soon as he realized that his mainframe didn t die.

Everyone said, loud enough for the others to hear, Look at Emperor s new process. It s the essence of agility!

What marvelous productivity! And the architecture! The architecture that has emerged from the code! I have never seen anything like it in my life.

They all tried to conceal their disappointment at not being able to see the architecture or smell the code, and because none of them was willing to admit their own stupidity and incompetence , they all behaved as the two gurus had predicted .

A young Java programmer from London, who was not afraid and could only see things his eyes showed to him, put up a small Web site with a contrary opinion. Emperor s process of DesignAfterFirstTesting is DAFT, he said. ConstantRefactoringAfterProgramming is CRAP. The whole thing is a bunch of daft crap, actually.

Fool! he was reprimanded on the newsgroups. You re afraid of agility! But the young programmer s remarks, which had been heard by the bystanders, were repeated over and over again until everyone cried, This is just a bunch of daft crap!

The book publishers realized that the people were right but couldn t admit to that. They thought it better to continue the book series under the illusion that anyone who couldn t smell the code was either stupid or incompetent. And so books continued to roll off the printing press.




Extreme Programming Refactored
Extreme Programming Refactored: The Case Against XP
ISBN: 1590590961
EAN: 2147483647
Year: 2003
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net