Slashdot Mirror

I was able to download a 'beta' version of the book a couple of months ago from here . I haven't read it yet, but I have read extreme programming explained which I thought was quite good (although like most people I have no practical experience in this kind of environment, although my current employer is getting close).

XP is not about being on time, under budget. XP is about giving the most business value to the customer at any given time. (And about writing [almost] bug-free code. And lots of other stuff..)

In a nutshell, you present 'stories' to your customer every 3 weeks, complete with estimates. Your customer gets to pick stories for the next 3 weeks that he deems most important. You go implement them.

Lather, rinse, repeat.

Since you do it every 3 weeks and adjust your estimate every 3 weeks, your customer always knows what to expect, and when.

But it's not about fixed budgets. (In fact, XP proponents also have proposed a different contract framework to adress this)

Try www.xprogramming.com for more info. (It has a PDF of XP installed, I think)

XP

It's worked wonders in my organization, and I suspect that the "war room" approach lends itself to similar types of productivity gains.

The 70-hour workweek is one aspect of some successful models of software development. Nevertheless, it is hardly a sufficient aspect. IBM and others have for years encouraged long hours and it seems in my experience this was just effort tossed away. Also, the extreme programming approach advocated by Jeffries and others puts a premium on proper design and pair programming work rather than isolated heroes, seems to be successful, and keeps within a reasonable workweek both so to not overly fatigue its participants and to be predicatable.

Simply put, a 40+ hour week is not sustainable for the long term. Further, it is not realistic as an HR policy. The participants will either get old enough to wonder about other things in their lives (and have made enough money so they can bolt and not give a damn) or pull back because of health reasons. And I really wonder about the ethics of an industry that says its doesn't care and demands such despite its effects.

Finally, one successful e-entrepeneur, Jeff Bezos, makes it a policy to demand he and folks around him get enough sleep. Or at least so he told the Wall Street Journal . It appears he's backed up by a lot of scientific evidence. There are recent articles about this in Kinko's IMPRESS magazine, the Washington Post, and the above-mentioned Wall Street Journal, unfortunately either only available for a fee or only in dead-trees form.

1. Gather Requirements
2. Make a Design Spec
3. Model the project (i.e. UML)
4. Code
5. Test
6. Goto 3

That's the way software engineers wish it worked. What actually happens is this:

1. Gather Requirements
2. Make a Design Spec
3. Discover ambiguities in Spec, goto 1
4. Model the project (i.e. UML)
5. argue incessantly about the one true way to model the project, goto 4
6. Code
7. discover what the model requires is either unecessary, impossible, or both, goto 1
8. Test
9. discover requirements have changed, because either conditions have changed or what you were asking the users to do (come up with a complete definition of how the software is supposed to work without any software in front of them to poke at), goto 1
10. Attempt to Goto 3, but discover that the code has drifted from the model and nobody kept the model up-to-date

This is why I'm no longer very interested in CMM Level 3-style Software Engineering. Some of the disfunctional behavior in the second list is avoidable, but some of it is inevitable as death and taxes. Venting at the stupid users for changing their minds once they see the software working (or sort of working), or at the stupid managers for letting them, doesn't actually accomplish anything. Even if you "win" the political battle of getting the users to accept the software as written to the spec, it's a Pyrrhic victory.

I've come to see that it's far better to grant the users the right to change their minds as their needs (or just their understanding of those needs) change in return for the right to use processes like Extreme Programming that will help me as a developer to meet those changing needs without running myself ragged, than dumping a year or more of my life down a rathole producing software that only makes people unhappy (if it gets used at all) because it was coded exactly to a completely outdated snapshot of what the users thought they needed before they and the world moved on.

Software development ought to be an ongoing conversation between the developers and the customers, not a one-way order from the customers to the engineers to produce a widget machined to the following specifications for delivery on such-and-such a date. Software development isn't there yet as an engineering discipline, and it's not even clear to me that's the direction that we ought to be going, since it gives up one of the most valuable and interesting properties of software (that it's "soft" and flexible).

A large, very successful contingent disagrees with that sentiment. The idea being that, if you can't test it yourself, you don't understand it well enough. It is your responsibility, as a developer, to ensure your code is as bug-free as possible before checking it back into --your VCS here--Extreme Programming says that relentless testing ensures trust in the code and enables rapid refactoring and progress.
XP has test frameworks for many popular languages.

A large, very successful contingent disagrees with that sentiment. The idea being that, if you can't test it yourself, you don't understand it well enough. It is your responsibility, as a developer, to ensure your code is as bug-free as possible before checking it back into --your VCS here--Extreme Programming says that relentless testing ensures trust in the code and enables rapid refactoring and progress.
XP has test frameworks for many popular languages.

Intentional programming is a pretty neat idea. IP basically provides an environment for programmers to develop extensions to a given language and to abstract code into "intentions". (It is a little unfortunate that a technology coming from Charles Simonyi at Microsoft is called "IP".) With an IP environment, you don't edit lines of code; rather, you edit (sort of) the abstract syntax tree, and you can express code in a notation of your own devising (which later gets translated into a target language).

Generative programming (see generative-programming.org is another new wave in SE. The idea behind generative programming is that you create metaprograms which then can generate programs or components, allowing you to build adaptable (meaning you can change their domain) or adaptive (meaning they self-adjust to a new domain) programs fairly easily.

Also look for eXtreme Programming and refactoring to become major new forces in traditional OO SE. XP is a new way to develop software; refactoring is a new way to maintain it. XP has end-users specify the requirements of an application by talking about how they'd like to use it; then developers, working in teams, code the application, designing as they go (except for some Class-Responsibility-Collaboration cards, which they make at the beginning of the development cycle). XP involves rapid development, frequent releases, and stringent unit tests. Refactoring provides a set of rubrics for improving the design of working code without breaking it, making code easier to maintain and understand while also providing better granularity for profiling and other instrumentation.

Out of all of these, I'm currently using XP, some GP, and refactoring -- and my productivity has soared.


~wog

You should try eXtreme Programming: http://www.xprogramming.com/

"Speaking of which, I wish they would disclose whether (and how much) the judges are paid."

I'm a judge. I'm not paid anything.

I'm a judge of the testing tool, which I hope doesn't cause as much excitement as make. For the record, I think JUnit, expect, and dejaGNU are all wonderful things. I agreed to be a judge not out of any disrespect to their authors. To me, Kent Beck / Erich Gamma in particular are way up there in the pantheon. JUnit, Extreme Programming, and all that are the most exciting things to have happened to testing in quite a while.

If someone comes up with a better extension or replacement, the testing world will be better off. If not, it will get ignored, with little or no harm done.

Python Promotion: I think it's important that tools have a good scripting language. I think using the same one across a suite of related tools is a win. I prefer Python to Perl or TCL (and Lisp to Python). But I probably would have been a judge even if the language were Perl, and I'm sure my Python bias was unknown when I was asked to be a judge.

"Speaking of which, I wish they would disclose whether (and how much) the judges are paid."

I'm a judge. I'm not paid anything.

I'm a judge of the testing tool, which I hope doesn't cause as much excitement as make. For the record, I think JUnit, expect, and dejaGNU are all wonderful things. I agreed to be a judge not out of any disrespect to their authors. To me, Kent Beck / Erich Gamma in particular are way up there in the pantheon. JUnit, Extreme Programming, and all that are the most exciting things to have happened to testing in quite a while.

If someone comes up with a better extension or replacement, the testing world will be better off. If not, it will get ignored, with little or no harm done.

Python Promotion: I think it's important that tools have a good scripting language. I think using the same one across a suite of related tools is a win. I prefer Python to Perl or TCL (and Lisp to Python). But I probably would have been a judge even if the language were Perl, and I'm sure my Python bias was unknown when I was asked to be a judge.

XP achieves everything CMM Level 5 calls for, except killing large numbers of trees. If XP's not Level 5, it'll do until something that is Level 5 becomes practical. See Ron Jeffries' XP CMM comparison for more reasons to think XP is what's worthwhile about Level 5.

A foundational part of XP is the mutability of code: you write the code for what you know now, and be willing in the future to totally change it. One of the best technical books I've read recently discusses the how-tos of this: "Refactoring" (by the way, the link directs you to a price comparison site which I find REALLY useful).

I tried to use this method is my latest project, a test framework, and I was extremely pleased by the results; not only did the design morph as I discovered the requirements (so the final result was a design I was pleased with), but the final result snapped into place around the item being tested and no bugs have been discovered in it!

I can highly recommend at least that part of XP: refactoring and coding for today. I'm going to try some of the other parts in small bits at a time, but from what I see they look very useful.

I certainly wouldn't describe XP as being for someone who doesn't have time to design; I would describe it as something for someone who doesn't expect to get it right the first time, and who wants to get it right anyhow. I would also describe it as being for someone who wants to be useful to customers without hurting his own productivity -- see the Bill of rights on the Extreme Programming website. In short, XP is about never having to tell a customer that you can't make that change now -- and it's also about always being able to make changes when you need to.

-Billy

There's actually a site *specifically* devoted to Extreme Programming now, which actually grew out of the site in the post to which I'm replying. The site is:

http://www.xprogramming.com/

This resonates with me. I wish the world worked this way. However, it doesn't seem to.

The way the world really works is described by Richard Gabriel in his paper usually called Worse is Better but which is really called "Lisp: Good News, Bad News, How to Win Big". If you want to make the world a better place then you need to know how it works. Otherwise, your attempts to change it will be futile. Most software development methods ignore the lessons of "Worse is Better". One method that pays close attention, and still manages to deliver quality software, is Extreme Programming. Extreme Programming does not work in every situation (for example, it requires small teams) but it handles market pressures well and pays very close attention to users.

Here is a link that might help:
XProgramming.com