Extreme Auto Shop

Note to contributors

There exists a 'Discussion' heading where contributors can express their opinion, i.e., provide feedback. Place your comments within this section.

Extreme Programming is an old idea

To best understand ExtremeProgramming, one need only think of taking your aging car to the repair shop. You begin by providing your mechanic (programmer) a list of problems (planning game story) with the car. Your mechanic (programmer) then prioritizes the needed repairs (results from planning game story) based upon what are the most needed repairs vs repairs that can wait (risk), how much each repair will cost (money) and how long it will take (time). Then you, based upon your bank account and your desire to have a running car back as soon as possible, tell your mechanic what repairs to make. Finally, your mechanic goes to work making those repairs that you authorize. After which, you agree upon your next meeting.

That's Extreme Programming in a Nutshell. It's hardly a revolutionary concept as people have conducted business like it for years.

Discussion

It certainly isn't intended to be revolutionary in the sense that it contains completely new ideas. It is a different social contract than what is common in many businesses that build software--self-estimation and frequent replanning in particular are foreign concepts.

No pair mechanics nor the customer watching the entire repair process?

Many shops will have traines or apprentices, many shops that have more than one wrench will work in a way that enables adhoc pair mechanics.

Build software? People write software using programming languages. People build physical structures like momuments, bridges, houses, and even physical machines that make use of virtual machines written (not built) in software to control them.

Feedback mechanisms are one of the hallmarks of complex systems the exhibit adaptability. Any order that does not make use of them is not an organization, simply. Orders that are organizations possess mechanisms for {self} estimation and {re} planning. Moreover orders that are organizations uses these mechanisms within feedback loops to adapt to their ever changing environment, i.e., business situations. If a company of people write software without these mechanisms, then their production, more than likely, will not result in useful tools.

I see some problems with this analogy:

The mechanics are repairing an existing mechanism: making it meet a preexisting specification defined by the manufacturer not the customer. An extreme programming team is building new software, working with the customer to determine the requirements.
I can't drive my car while the mechanics are working on further repairs. But in an extreme programming project releases are used by the customers while the programming team are working on the next iteration.
I don't sit in the repair shop all week answering questions while the mechanics work on my car. I don't need to because the specification of what the car should do is defined by the manufacturer and any applicable laws, not by me, the customer.
The mechanics don't record metrics and give me constant feedback on the progress of their work. They certainly don't use those metrics to improve their ability to predict how long the job will take. Maybe I should go to a different autoshop!

Being a contrarian is no excuse for lacking the ability to see the analogy. Here's where your commentary is factually incorrect.

1. refutation of point 1

a) The customer makes pre-existing specifications when they choose the automobile that meets has their desired features within the face of constraints. All computer systems and computer system buys are exactly like this. No entity is capable of buying a computer with unlimited features or power.

b) No one builds software (what an overused and incorrectly used phrase). People write software that expresses their ideas. Humans build concrete objects. e.g., 'building a building'. Programmers (a truncation of program writers, which are not engineers) write software for existing software systems as well as new software systems. Your claim that EP is for new software writing only is false.

2. refutation of point 2

In the real world, software development and implementation often leaves many aspects of systems incapable of use temporarily.

3. refutation of point 3

You're playing with words here with respect to the concept of length of Q&A sessions, which is irrelevant.

4. refutuation of point 4

Apparently, either you have very little experience with auto mechanics or you do not hold them in high regard. Mechanics keep the metrics in their heads during the course of repair. Moreover, their accumulated experience provides them with the ability to estimate the big picture and any component parts of the repair cycle as the reparations are ongoing. If you want to obtain a report of the metrics, then pick up the telephone and call your mechanic. Your mechanic will be able to give you a full report, ad hoc about the entire state of the repair cycle!