After reading some comments, I did some more research. It seems the author of the paper "Worse is Better" also wrote an article called Lessons of the science of nothing at all
XP, Agile, Open Source. heh. Who'd have thought?
Re:gee...he really needs to shorten that and tight
chromatic on 2003-10-24T22:44:16
In my experience, 90% of programmers think they're in the top 10% of programmers worldwide. Also in my experience, most of us don't comparee to Beethoven or Twain. (Not even Liszt, and I don't like him one bit.)
Re:gee...he really needs to shorten that and tight
hfb on 2003-10-24T23:02:18
Well, tell a Sysadmin something we don't know already:) But, pick an art, any art, since most programmers do tend to liken what they do to an art...then find one of those that exhibits any sort of 'Xtreme' practises. I just haven't seen or heard anything about it to make me think it is anything more than a fad. I'd be terrified to find groups of sysadmins huddling around one console save only in the most dire of circumstances...like a system crash or viewing porn while waiting for pizza. Re:gee...he really needs to shorten that and tight
jordan on 2003-10-25T13:33:33
- But, pick an art, any art, since most programmers do tend to liken what they do to an art...
Programmers may liken what they do to artistry, but that's mostly hubris. It's more of a combination of Artistry and Engineering and ultimately, commercial development is more about Engineering.
Perhaps Architecture is the closest thing to it.
Unfortunately, unlike Architecture, there isn't thousands of years of best practices to draw upon. Also, in Architecture, designs are realized in an abstract but detailed form long before implementation. Engineers who have strict implementation guidelines are required to realize those designs into concrete and steel.
This builds in a real review process on designs that usually results in a better final product. This handoff between design and implementation isn't always perfect. A few years back, there was a failure of a walkway/bridge at a motor speedway here in the US. In turned out that the Engineer, to cut corners, used two half-sized support elements when the design called for one long support bar. The point where those two elements joined was a weak point that resulted in the structure failing under load and killing a number of people.
In Software, the typical case is that a programmer is responsible for design and implementation. Due to commercial realities, like deadlines and lack of thought to ongoing support, corners are cut in both design and implementation. I think that Pair programming is an effort to deal with problems that arise from taking these shortcuts. One person may say to themselves that they can get away with sloppy practices that they wouldn't let someone else get away with, but two will not. Detailed documentation and code reviews have been more or less failures to deal with these problems as these are always realized late in the process when the commercial pressure of deadlines are most powerful. Pair Programming tries to deal with these problems up front. I think Pair Programming is a sneaky effort to get Management to accept good review practices.
I'm not sure if this is best or not. Ultimately, I like to think Open Source deals with some of these problems in a more fluid fashion. Sure, most programmers aren't the equivalent of Twain or Beethoven, but some are. If everyone is allowed to build upon their works, improving and pruning in an evolutionary process where good changes win and bad changes are dropped, perhaps a better software base can be built up for all. Open Source addresses the problems of commercial pressure on development by ignoring it completely. I think that the reason Pair Programming is extremely rare in OSS coding is that there are no commercial release pressures that dictate it's necessity.
I also agree with Chromatic's recent comments elsewhere that OSS advocates tell themselves a lot of lies about OSS quality. However, on average, I find the quality of OSS to be as high or higher than closed software. I've seen some unbelievably bad code in production closed source systems and there's really no mechanism to correct it. In OSS, someone would just correct the crap and put out a new version. It's difficult to get Management to buy into code changes if what's in production is "working".
As always, just my thoughts, I'm no expert, your milage may vary, void where prohibited by law, Jeep is a registered trademark of Daimler-Chrysler, etc. etc.
Thanks for posting this. I had heard of Gabriel while slowly digesting The Timeless Way of Building by Christopher Alexander. I might be wrong but I think Gabriel was one of the first people to apply Alexander's idea of pattern languages to software.
A wonderful essay, which isn't about Extreme Programming, as much as it is about what goes into the creation of software, and the nascent ideas on how best to go about doing it.
I particularly liked the section on opensource:
Lovely. And it reminded me of one of my favorite authors' booksImagine that you open up your hood and what you see is sand. Open up your TV - sand. Look in the back of your refrigerator - sand. Unscrew any access plate anywhere in your house - and it's more sand. Change or move one grain of it and - ka! boom! - it doesn't work anymore or does something you don't like such as show only the Home Shopping Network, heat up your ice cream, or make your car go only backwards honking the horn. Sounds a little nuts doesn't it?
But that's exactly what software is like. The software in a form that people have a chance to understand is transformed by the software maker into something only a particular set of computers can understand, and that's what you buy. Even if you were capable of finding and fixing a bug in Microsoft Word, you couldn't do it unless you worked for Microsoft.
Let's go back to the real world example. If the innards of your car were like software, then when it needed to be fixed, the original manufacturer would have to be contacted. They would prepare a new batch of sand, and that batch would replace the sand in your car.
Ask a software company why they want you to not even see what is inside what they sell and they will tell you that either it's too complicated for you to understand or that this way they can protect their trade secrets.
