EXTREME Programming

[evildave]

Anybody have credible links about true "Extreme Programming" successes when applied to large projects?

(Not "my work days got better" stories: Large products COMPLETED, and SHIPPED to public or to a (at least relatively) satisfied customer. Within a broad horizon of its timeline and budget. Relatively defect-free.)

I have a bunch of inexperienced kids working at my current job who believe (quite sincerely) that XP is THE WAY. The technical lead seems to have bought into it, too. He should know better - or perhaps he knows all too well.

Funny, but it all reads to me like a hyped up dot-com business plan (http://www.extremeprogramming.org/). Without any effort at all I've found first-hand accounts of projects destroyed by it, some directly recounted by people I know. (Even the archetypal cited 'XP' example (C3 - a Chrysler payroll system) that got all of the first XP books written was a cancelled project - an utter failure! It never even routinely handled more than 1/10th of the job it was supposed to before they dumped it!)

I can see how this "philosophy" would appeal to a lot of people. Just start hacking immediately like you would in your mom's garage, and POW! Your project will be completed with no design, or even clearly defined goals, and no boring things like documentation. AND you don't have to deal with those mean old QA people and all their negative feedback! Best of all, nobody but YOU can measure the progress!

What a dream for the naiive (or criminal). Its proponents sound like the people who wax eloquent about how well horoscopes guide their lives, or the vast power of prayer to cure any disease.

At the moment, the part of the team that uses "extreme programming" never seems to have a build that works. The most outspoken proponent of the scheme (a very junior programmer) says "the literature supports it".

Not any of this literature....
http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp
http://www.agilealliance.org/articles/articles/XPConsideredHarmful-GeraldKeefer.pdf

The same kid also qualifies design decisions like re-inventing a whole (inexpensive and proven) commercial animation library in-house like this: "it sucks".

The kids all seem to like the XP practices, though. Maybe because it has an 'X' in it, for 'Extreme'.

I have learned one thing: if "Extreme Programming" practices are ever mentioned as "in place here" in a job interview, I will probably not seek any work there. Of course, if I just want to work where progress isn't measurable, on a project that will never see the light of day, for some fixed period of time (i.e., up to a few months before it's "supposed to be finished" so it can be referenced on a resume`), it seems ideal.

I must be getting old or something.

[Zep]

Bet they haven't got a written down methodology either. In which case, ask two of the proponents to stand side-by-side and explain it to the boss/customer who is paying for all this malarkey.

Sorry about the sore arses from the big boots, kids! Have a nice drive to your next jobs...

[Terry]

Originally posted by evildave

I can see how this "philosophy" would appeal to a lot of people. Just start hacking immediately like you would in your mom's garage, and POW! Your project will be completed with no design, or even clearly defined goals, and no boring things like documentation. AND you don't have to deal with those mean old QA people and all their negative feedback! Best of all, nobody but YOU can measure the progress!


Well, that may not be entirely fair. A "story" is only done when the customer agrees it is done. Sound pretty objective to me.


At the moment, the part of the team that uses "extreme programming" never seems to have a build that works.

DANGER! DANGER! In XP, every build is supposed to work. That's the whole frikin' point. I'm not sure I completely buy XP, but to be fair, it doesn't sound like this bunch is actually doing XP.

--Terry.

[jimlintott]

I program for fun as a hobby. I had never heard of this XP thing before so I googled it. I found this site (http://www.extremeprogramming.org/index.html). I read quite a bit of it and it struck me as being a bit woo-woo. I can't see anything here that wasn't done before. Isn't the task always to make the customers happy, deliver on time, and write good code? I don't see what has changed?

I guess I don't get the 'Extreme' part. What is so different and how is it different? The site I found had much about why it is different but very little how it is different.

[Wudang]

For 8 years I was a software tester and I've seen ideas come and go. I'm interested in extreme programming because it looks superficially like some of the practices of the best team I've ever worked with. If you look at some of the articles chained off the developerworks site at IBM you'll see some articles that discuss the necessary conditions. Big thing from my experience is the emphasis on educated programmers. Otherwise it's like (true story) people taking C code, running it through a C++ compiler and thinking they were doing object-oriented programming.

[roger]

To be fair, Jim, that site is long on praises and short on description.


XP, which I don't advocate, consists of a combination of practices which are not common, including hese:

(the rationales given are the rationales of proponents of XP, not mine, so please don't argue with me about these points! Trust me, if you disagree with what follows, I probably agree with you. I'm just trying to be fair in presenting the XP side)

* pair programing - 2 programmers get 1 computer. 1 types, the other watches and comments. The premise is that since code reviews catch so many bugs, doing a code review during coding is best. Further, it is supposed to be an excellent way to mentor a junior team member.

* daily builds - this is common. Build every night and run your full test suites. Fix any faults before continuing (this is the source of the comment that if the builds weren't working, they weren't doing XP)

* test harnesses - you write your test code BEFORE you write your code. Every function gets a harness. This forces you to think through what you are trying to accomplish, and of course, facilitates testing the daily builds.

* refactoring - designs 'evolve'. Each day you add functionality, but you do not design any module to do _any more_ than it needs to at the moment. You _do not_ design with the future in mind. When it comes time to implement that future requirement, you 'refactor' the design.

There's more, but I forget. It's documented in the book Extreme Programming, which I have, but it is packed up tonight because I am moving my office.

There's a lot I dislike about XP, but one thing about it reflects something I have thought a long time about alternative methodologies for designing software. Most methods focus on the design of new s/w, followed by implementation. However, if you look at the lifecycle of a typical, successful project, the majority of the software work occurs during maintainance.

In my career I have seen so many originally clean designs slowly hacked and band-aided into incomprehensible messes that had to be thrown out after one to many 'fixes'. I consider that a fault of how people are trained to create new software, but not how to modify existing software. XP, at least, recognizes that the ability to refactor code is critical to any project.

[jimlintott]

Hey thanks. You make more sense than that web site.

Doesn't sound completely crazy.

Does it work better for some types of projects than others?

[Janus]

We are looking at XP for our office. From what I've read, I consider it to be on paper no less plausible than any other development methodology.

Some random thoughts from the top of my head:

XP appears to be incremental and/or exploratory development, with processes in place to improve code reliability, and keep management happy.

Features are delivered in short cycles. The customer chooses what feature is to be implemented next, and features are normally described in terms of what the client expects to do.

Code is written to meet todays requirements. If existing code is inadequate, then it should be re factored/replaced. Unit tests and functional tests should detect breakage of existing functionality. Tests, both unit and functional are written first, so that success is clearly defined and to serve as meaning full documentation on what the code is to accomplish.

Programmer performance is measured with metrics, such as the difference between there estimated completion time and their actual completion time. Long term trends are used to guide management in load distribution.

Pair programming: Blosters weaker programmers. One programmer thinks stragicaly while the other is working. Roles are switched frequently and pairings are only for the duration of a feature.

Theres more but I cant remember it all. The books I've read spend alot of time dealing with how XP addresses the short falls that are occuring today in software engining.

XP is ideal for cases where firm and accurate client requirements don't exist (Often they appear to exist, but clients can be very fickle).

When we start implementing it, I'll let you know how it goes.

[roger]

This link (http://www-personal.umich.edu/~nsshami/CIS518/xpStart.html) seems to list all the core attributes that I remember. The hardest one to swallow is the requirement to have a client onsite during the entire development. Right! Try that when developing software for the military, or for an office of lawyers for that matter.

programmer: just one last thing. We will need one of your lawyers onsite for the next year and a half, full-time.

client: (sputtering) that represent's a loss of a minimum of $3M in billible hours.

programmer: But it's extreme, dude.

[Yahweh]

I used to program as a hobby for fun (until I lost my Visual Basic disk...), I still do every now and then (with ASP/ADO). If I have an idea, I think about until I get the energy to start making my ideas into reality. I usually have nothing more than "a sorta idea of what I want, I'll think about design later".

My most current project (its only something I've been thinking about possibly getting around to bringing myself to consider doing) something along the lines of a blogging tool. It would most likely be completely database driven (thats dangerous if your server hacked or killed without warning) interface that requires absolutely no knowledge of HTML from the user. I would call it YBlogger.

If I ever turn YBlogger into reality, maybe I might contemplate eventually selling my finished product.

Its computer programming... TO THE XXXTREEEEMMMMMEEEEEE!!!!!!!

[Zep]

Originally posted by Janus
We are looking at XP for our office. From what I've read, I consider it to be on paper no less plausible than any other development methodology.

Some random thoughts from the top of my head:

XP appears to be incremental and/or exploratory development, with processes in place to improve code reliability, and keep management happy.

Features are delivered in short cycles. The customer chooses what feature is to be implemented next, and features are normally described in terms of what the client expects to do.

Code is written to meet todays requirements. If existing code is inadequate, then it should be re factored/replaced. Unit tests and functional tests should detect breakage of existing functionality. Tests, both unit and functional are written first, so that success is clearly defined and to serve as meaning full documentation on what the code is to accomplish.

Programmer performance is measured with metrics, such as the difference between there estimated completion time and their actual completion time. Long term trends are used to guide management in load distribution.

Pair programming: Blosters weaker programmers. One programmer thinks stragicaly while the other is working. Roles are switched frequently and pairings are only for the duration of a feature.

Theres more but I cant remember it all. The books I've read spend alot of time dealing with how XP addresses the short falls that are occuring today in software engining.

XP is ideal for cases where firm and accurate client requirements don't exist (Often they appear to exist, but clients can be very fickle).

When we start implementing it, I'll let you know how it goes. REAL companies grew out of this mode of thinking about coding in the 1950's. The cost overheads turned out to be enormous, compared to the concept of "planning ahead."

I agree that SOME of the programming methodologies used today ARE time and resource wasting (Object Oriented, for a start). However XP is nothing more than throwing the baby out with the bathwater.

[Janus]

Horses for Courses

Originally posted by Zep
The cost overheads turned out to be enormous, compared to the concept of "planning ahead."

In some environments, planning ahead is essential. In our environment, many plans are obsolete before they are finished, and none survive there intended lifetime. XP doesn't eliminate planning, just reduces is scope, focusing on the most immediate requirements.

Originally posted by Zep
I agree that SOME of the programming methodologies used today ARE time and resource wasting (Object Oriented, for a start). However XP is nothing more than throwing the baby out with the bathwater. [/B]
Most methodology's are created because the creator considers existing methodologys to be incompatible with their environment. If existing methodologys were actually useful to us, I would be more concerned about abandoning them.

Anyway I truely can't defend XP (yet). We are looking at it because it appears to be better than what we are doing now. If it turns out that its not, it can be placed on the pile along with all the other failed attempts to improve our work flow.

[a_unique_person]

I think that 'make a build every night' theme is half of Microsoft's problem, as they used it for developing NT.

You do need a roadmap, but the beauty of a properly designed software system is that, if you use good engineering principles, you can add on the bits you need later without necessarily knowing exactly how they will work.

The relational database, for example, is perhaps the most enduring and successful development in modern software. Just as long as you build normalised tables, you don't have to have any idea of how the whole database will fit together in the future.

The SAP system uses it, and new tables are continually added. It all still hangs together, despite the fact that the number of tables is now over 10,000. The design decisions have mostly been pretty painless, except for the mistakes they made when they first got it going and still had some hierarchical data structures in there.

A good object oriented software system is more concerned with the interfaces between software components. If these are defined in a consistent manner, you should be able to hook up the relevant modules in a similarly painless manner. From what I have read, Java has tried to achieve exactly this. Multiple programs can hook up to the same interface and work correctly.

The concept I like about the XP concept is the 'team' programming example. Review the stuff up front. But don't think that this means the review process is finished with there and then.

[evildave]

So, basically nobody can give me a link to a project that used XP and was successful.

To be "fair", building unit tests and promoting automated testing is what we "old fashioned" programmers keep promoting, which the XP worshipers don't ever have time to do. As well as making code that doesn't "just crash" over trivial errors, possibly even giving useful feedback to OTHER people who occasionally want to check what their stuff looks like in the game.

Part of the problem here is there is a client and a server half. For some reason, we on the server side (who will wear pagers) don't believe that a server with thousands of users on it should crash. Especially not on evenings, weekends and holidays that we'd rather spend doing something else. Planning a little ahead about how things will communicate and handle problems, and automatically recover from them; that sort of non-XP thinking.

The client half believes that it's A-OK not to check for or handle error conditions (not even asserting them) because that's "extra work". "YAGNI". With their design, if the server sends down a reference to a non-existant resource, it "just crashes". What that means is, if a new kind of weed is on the terrain, and a texture is missing, people will crash at random whenever that weed comes into view. However long it took to set up a test, with however many hundreds of people: RUINED for one trivial oversight that could have displayed a red box where the missing weed was. Too bad.

Of course, so much of what you ALSO need to test can't have an automated unit created for it. Emergent behaviors and bad interfaces (as well as unexpected inputs) have to be created with human input. That means live testers and feedback. A unit test is absolutely valueless in these cases. Scripting and recording would be valuable, as well as error trapping and automatic reporting, but these will just plain never happen. The client team sees no value in being notified of their own problems in a clear and unambiguous manner.

Basically, my experience with "Extreme Programming" is that it's something useless slackers came up with to excuse never being able to commit to a design.


I've got a great idea for XP proponents. Have your next home or home improvement built using XP practices. Don't plan your new deck. Just buy lumber and start nailing it together without measuring anything. Your wife can be the stake-holder. Just solve problems as you discover them. Designing and planning ahead are for wimps. That's why the hammer has that claw on it: to tear down what you mess up.


Imagine if they build the Golden Gate bridge with XP principles:

First, pretend the construction materials are free. After all, changing code is just changing state. So, disregard the cost of getting materials. Just start with a labor force that gets paid for four years whether they produce anything or not.

They'd have started by putting a single rope across the bay and when that didn't work, they'd have torn it down and suspended two ropes. They would proceed to build and evolve bridges all the way from the most primitive and naiive deisgns toward things that seem more robust. Each time they built a bridge that appeared to be becomming unsatisfactory, they'd just blow it up and start over.

They wouldn't have built it where the highways and population centers were, because there would be an equal chance it would go to Oakland instead of where it did. They'd try to build the bridge where it could change direction, and in a manner where it could easily change direction.

The architects would keep a city representative who (magically) is not affected by people wondering where their tax dollars are going, and why there's no measurable progress on the bridge project, who can change his fickle little mind on a whim about anything in the project at any time.

At the end of the project, the bay would be impassible to maritime traffic for all the bridge debris, and the actual bridge would be a rickety 30 foot wide overpass built 60 miles east of the place it needed to be, where it does the least good, because that's would be the most flexible place to put it, and all the they could do with the time left to them.

There was a bridge built. In the allotted time. Contract complete and successful. The architects then proclaim an amazing technical acheivement based on the bridge standing for a few months before it's condemned for being unsafe, and write volumes about their amazing technique.

http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf

Click through this PDF link to see a newer version of the "harmful" document, with more about how the archetypal XP project (C3) is exactly this bridge example, and the SECOND XP project turned out much the same.

Sounds like a lousy model to pattern your work practices after, even if done right, and probably very few do it right.

The 2nd edition of the paper includes new facts and research results that further solidify my concerns
with regard to Extreme Programming:
1. It is a set of practices that is only in very rare cases applicable –and applied- “by the book”.
2. It relies to a high degree on the skills of individuals and their tacit knowledge.
3. It does not explicitly manage quality in the sense required by any major quality standard.
4. It does not scale up to larger projects.
5. Some practices, such as pair programming, have not been validated for their efficiency and are
promoted based on anectodal evidence.
The following facts have been updated or newly introduced:
1. Not only the first, but also the second Extreme Programming project was cancelled.
2. Kent Beck’s flattened cost of change curve phantasia is dismissed even inside the agile
movement.
3. Several empirical research results question the usefulness of pair programming.
4. Initial empirical research results question the feasibility of test first programming.
5. Reports from larger Extreme Programming projects indicate that the anticipated scaling problems
are indeed valid.
Beyond justified criticism, however, there are agile lessons to be learned:
1. Any process that is actually applied is far superior than a perfect paper process that is not applied.
2. Traditional planning processes do not sufficiently address operational planning.

[Wudang]

I read up a bit more, especially about pair programming, where I'd just skimmed before. I guess what I was talking about before might be on the fringes of agile programming but this pair programming is bizarre. The team I worked with btw was extremely skilled and experienced and guys like them can get away with murder and still get the job done.
I dunno, I've seen methodologies du jour come and go ("cleanroom" anyone?) and I've come to the conclusion that once the number of programmers is greater than one you need good project management to keep on track and in control. Too many of these bright ideas seem to come from academia where 2 people writing a couple of hundred lines of code "conceptually" proves the concept.
I have to speak up in defense of OOPS though. As someone who's had to work his rear off when a change was needed to an assembler macro or COBOL copybook, checking SMP or Endevor for all the dependencies, I'm all for it.

[a_unique_person]

Originally posted by Wudang

I have to speak up in defense of OOPS though. As someone who's had to work his rear off when a change was needed to an assembler macro or COBOL copybook, checking SMP or Endevor for all the dependencies, I'm all for it.

Hmmm, Endevor.

[Wudang]

Originally posted by a_unique_person


Hmmm, Endevor.

Oh, sorry. That should have been End*v*r in the interests of decency. My apologies to those of a sensitive disposition.

[Ed]

Originally posted by evildave
Anybody have credible links about true "Extreme Programming" successes when applied to large projects?

(Not "my work days got better" stories: Large products COMPLETED, and SHIPPED to public or to a (at least relatively) satisfied customer. Within a broad horizon of its timeline and budget. Relatively defect-free.)

I have a bunch of inexperienced kids working at my current job who believe (quite sincerely) that XP is THE WAY. The technical lead seems to have bought into it, too. He should know better - or perhaps he knows all too well.

Funny, but it all reads to me like a hyped up dot-com business plan (http://www.extremeprogramming.org/). Without any effort at all I've found first-hand accounts of projects destroyed by it, some directly recounted by people I know. (Even the archetypal cited 'XP' example (C3 - a Chrysler payroll system) that got all of the first XP books written was a cancelled project - an utter failure! It never even routinely handled more than 1/10th of the job it was supposed to before they dumped it!)

I can see how this "philosophy" would appeal to a lot of people. Just start hacking immediately like you would in your mom's garage, and POW! Your project will be completed with no design, or even clearly defined goals, and no boring things like documentation. AND you don't have to deal with those mean old QA people and all their negative feedback! Best of all, nobody but YOU can measure the progress!




Is this related to the XR (extreme research) done in the paranormal? Sounds sorta like Schwartz et al.

[Terry]

Originally posted by evildave

I've got a great idea for XP proponents. Have your next home or home improvement built using XP practices. Don't plan your new deck. Just buy lumber and start nailing it together without measuring anything. Your wife can be the stake-holder.

I'm not an XP proponent. But I don't think it is entirely devoid of value. Clearly you have had a bad experience here. I'd just like to make two points. First, slackers will be slackers, whether they are doing XP or any other methodology. Second, software isn't the same as physical construction. The same constraints (particularly in order of doing things) do not obtain.

Three points (fear suprise and...) XP doesn't say "You don't need error handling". Your bunch of slackers say that.

--Terry.

[Skeptoid]

Terry wrote:
Three points (fear suprise and...)
:D

[evildave]

Originally posted by Terry


I'm not an XP proponent. But I don't think it is entirely devoid of value. Clearly you have had a bad experience here. I'd just like to make two points. First, slackers will be slackers, whether they are doing XP or any other methodology. Second, software isn't the same as physical construction. The same constraints (particularly in order of doing things) do not obtain.

Three points (fear suprise and...) XP doesn't say "You don't need error handling". Your bunch of slackers say that.

--Terry.

Actually, for the bridge example, I granted that the construction materials were "free".

The problem is, labor is never free. And that's what puts the cost into anything, whether it's physical or virtual.

On top of this, for any non-trivial system, you'll need to design a framework for it up-front. You can't change this framework without cost. Sure, you don't have to get hydraulic jacks in to lift the deck up off the soil so you can add those concrete footings you forgot, but there is significant and time consuming effort involved in "refactoring" things.

In a software system that has to STAY RUNNING (and compatible with installed software) while you attempt the refactoring, it's pretty much exactly like getting the hydraulic jacks in to lift it up. You have to prop up what you're about to replace or modify. You have to test it to ensure it will work when you remove those props, or there's every probability it will fall down.

Sure, version control will let you "revert back" to previous running versions... but that's pretty much like rebuilding the deck just like it was with the problems before you had to start tinkering with it some more.

And if the code is just a long string of nasty hacks held together with krazy glue and duct tape (the sorts of "simple" things these "Extreme Programming" clods seem to think is best), there's hardly any loose thread you can tug on without unraveling the whole thing.

I love mixed metaphors. In writing, anyway.

I take a long-term view of what's simple. If I can write a tool or library that will make aspects of the project trivial to change, I tend to plan ahead for and write them. These tend to look "complex", and do occasionally contain a bit of YAGNI content for certain applications. But when I can change a macro or template in one place and modify idiot-proof global behaviors everywhere they occur (like messaging protocols), it's handy. Too bad the "XP" dimwits decided it looked "too complicated" and wrote their own (sort-of) compatible and "simple" protocol that routinely breaks down and needs time consuming "refactoring".

[Janus]

Originally posted by evildave
The client half believes that it's A-OK not to check for or handle error conditions (not even asserting them) because that's "extra work".

No methodology will make people less dogmatic and more intelligent. Also under xp you (the server author(s)) would be playing customer to the gameclient authors. If the ability for the client to handle unexpected resource requests is important to you, then you should be demanding it.
Originally posted by evildave
Of course, so much of what you ALSO need to test can't have an automated unit created for it.

True. Functional testing is an attempt to address this. Its not a magic bullet, but you should at least you end up with a good checklist. If you pass all the items on the checklist, then you know the software does everything that the customer has asked for (so far).
Originally posted by evildave
The client team sees no value in being notified of their own problems in a clear and unambiguous manner.

xp is all about being notified about problems in a clear and unambiguous manner. Your "xp" programmers are morons.
Originally posted by evildave
Basically, my experience with "Extreme Programming" is that it's something useless slackers came up with to excuse never being able to commit to a design.

1. No methodology can prevent people being useless slackers
2. 40% of the code I have written over the last two years has been abandoned. Not only is that code wasted, but effort that I put into attempting to future proof the code has been wasted. xp is not anti design, but anti premature design. If you know what you require, go with it. If you don't, don't pretend that you do. You should be writing well organised code regardless, and if you find that your current implementation is lacking, then a good tests regime and clean coding will allow you to make changes with confidence. If you cant write good tests or clean code, don't try xp.
Originally posted by evildave
I've got a great idea for XP proponents. Have your next home or home improvement built using XP practices...

Imagine if they build the Golden Gate bridge with XP principles:

If civil engineering methods worked for software engineering, there would be no discussion.

Originally posted by evildave
http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf

Click through this PDF link to see a newer version of the "harmful" document, with more about how the archetypal XP project (C3) is exactly this bridge example, and the SECOND XP project turned out much the same.

Your bridge parable overlooks the fact that “the project was in a mess” before they move to xp. Also this was the first attempt to apply xp in the real world, and it wasn't exactly a disaster: The pilot program was handling 10,000 people a year before the scheduled delivery date. The ability to cope with 87000 persons information on a weekly basis is the kind of requirement that should sound warning bells no mater what project methodology you intend to use.

Originally posted by evildave
Sounds like a lousy model to pattern your work practices after, even if done right, and probably very few do it right.

Its not for every project. If you have clear and detail requirements up front, you probably don't need xp, but even then xp appears contains good ideas that will play well with other methodologies.

[Terry]

Originally posted by evildave
So, basically nobody can give me a link to a project that used XP and was successful.

To be "fair", building unit tests and promoting automated testing is what we "old fashioned" programmers keep promoting, which the XP worshipers don't ever have time to do.


I don't know why, but this thread has a strange attraction to me. Like picking at a scab - I know I really should leave it alone...

So you have some coders who say they're doing XP, but they "don't have time to write tests"? They simply aren't doing XP.

http://c2.com/cgi/wiki?AlmostExtremeProgramming

--Terry.

[Janus]

Originally posted by evildave
In a software system that has to STAY RUNNING (and compatible with installed software) while you attempt the refactoring, it's pretty much exactly like getting the hydraulic jacks in to lift it up. You have to prop up what you're about to replace or modify. You have to test it to ensure it will work when you remove those props, or there's every probability it will fall down.

There are only two ways to limit the risk in systems that must be reliable.
1.never ever ever modify them. Designing systems that will never ever need to be modified is quite a challenge.
2.Design tests that cover the entire system. Also quite challenging
xp makes 2 viable by making tests the authoritative description of the system. Every single detail from features, to protocols to performance requirements- every single expectation, must have tests associated with it. If the software passes all tests, but doesn't for fill your expectations then you have not written enough tests.

Originally posted by evildave
And if the code is just a long string of nasty hacks held together with krazy glue and duct tape (the sorts of "simple" things these "Extreme Programming" clods seem to think is best), there's hardly any loose thread you can tug on without unraveling the whole thing.

if anybody that works for you wants to write code like that.... fire them. There is no excuse.

Originally posted by evildave
I take a long-term view of what's simple. If I can write a tool or library that will make aspects of the project trivial to change, I tend to plan ahead for and write them. These tend to look "complex", and do occasionally contain a bit of YAGNI content for certain applications. But when I can change a macro or template in one place and modify idiot-proof global behaviors everywhere they occur (like messaging protocols), it's handy.

Silly xp mantra : Do everything once only. Centeralising code is not only good practice, but its mandated by xp. Writing good, neat, modular, centralized code is essential to the success of xp (You Are Going to Need It). If they are using xp as an excuse not to do these thing, then they truly have no clue.

Originally posted by evildave
Too bad the "XP" dimwits decided it looked "too complicated" and wrote their own (sort-of) compatible and "simple" protocol that routinely breaks down and needs time consuming "refactoring". [/B]

Too bad the programmers are nether good at programming, or at xp.

[peptoabysmal]

Originally posted by evildave
At the moment, the part of the team that uses "extreme programming" never seems to have a build that works. The most outspoken proponent of the scheme (a very junior programmer) says "the literature supports it".


I concur with this finding. It does seem to help in very specific cases of debugging a particularly nasty bug, but, like you say, the part of the team who uses this practice in our office never seems to get the job out on time and it never seems to work all that well.

But, I'm getting old too :p

Edited to add, the best instructor I ever had also worked for Sun and his philosophy was simply these three steps in this order:

1) Make it work

2) Make it work better

3) Make it work faster

[evildave]

Oh well.

I'm not the lead.

The people with "XP" in their heads are the leads. Bosses of my (reasonable and good at deflecting this BS from us) boss. And they're the "shut up and do it my way" types. There are meetings to "discuss" design. These are just for "buy-in". Essentially all input is rejected and the "solution" the lead brought in is "decided on" at the close of the meeting. Of course, a year down the road and 30+ people on payroll, and there is no design. Silly me. That's "XP" again.

As for it not being "XP", or whatever, it doesn't matter. There are gems among the turds, but it feels a lot like the "infinite monkeys typing" problem: yes, all the great works of literature will be in that mess, but do YOU want to sift through infinite quantities of paper soaked in monkey debris to find them?


Now, the first thing that caught my eye about the latest link: NO CODE COMMENTS as a "reward"! (A truly useful bit of ammunition, that "almost" bit, though.)

What sort of "reward" is that?

I find it's very helpful to type out what the functions are, what their parameters do, what the results should be, and THEN type the code. When I write a class, I spend the extra minute or two to type a note about what the class does and what its parts are for. It takes no time at all when I just type the comments as I type the code.

What sort of "reward" is not documenting a million lines of code?

Certainly not much of a reward to anyone who has to come in later to clean up any messes.

The only "reward" from not typing some code comments is that you will forever be forced to TOTALLY reverse-engineer the code other people on your team write, and even your own code.

*OUR* "XP" programmers think comments "clutter" the code and make it hard to read. Another notable feature in the client code is that the only comments you will find are the sorts of things like pasted comments identifying "constructors and destructors" (have you ever had a problem identifying these???), but none identifying what a single class member variable or function does.

They probably peel the labels off their circuit breakers, too. After all, once you personally know which circuit breaker will black out every computer in the office, nobody else needs to know that. It's all just so much "clutter". Seeing a row of black, anonymous switches is so much clearer than switches with little labels next to them with room numbers and notes like "lights" and "kitchen" and "A/C".



BTW, we have an enumeration of message identifiers. I.e.

enum
{
msgPing,
msgConnect,
msgAckConnect
....
};

The client team doesn't want to share our code to the point where they defined their own enumeration IN PARALLEL (to go along with their similar but not really identical serial parsing). There is no permission to be had to fix such blatant butt-headed issues. "No time!" And you're "inventing problems" if you go and bring up anything as "trivial" as this.

Especially now that we're in a "crunch mode" for a demo. Amiga demo all the way.


Perhaps I should spend my upcomming and inevitable unemployment more carefully selecting my next career direction.

[Zep]

Let me turn this "XP" concept back on the programmers.

Would they EVER buy a program - operating system, compiler, word processor, game, whatever - built using XP? All these products have "time constraints" on their production (ask jj!) and are built to constantly varying customer specifications. Do they think that the results would be any MORE reliable or meet deadline if they were just assorted chunks of (possible well-written) code tossed together because "that looks about right"?

I would suggest that XP is the providence of the fly-by-night hacker who can produce reasonable code in coffee-fueled bursts, but has no idea of what a REAL COMMERCIAL product ACTUALLY looks like.

I'm with evildave on this - wouldn't touch it with a ten-foot bargepole.

[Janus]

Originally posted by Zep
Would they EVER buy a program - operating system, compiler, word processor, game, whatever - built using XP?

If the software actualy works, I wouldn't care if it was designed with tarrot cards.

Originally posted by Zep
All these products have "time constraints" on their production (ask jj!) and are built to constantly varying customer specifications.

All of these products are routinely delivered late or with less features.

Originally posted by Zep
Do they think that the results would be any MORE reliable or meet deadline if they were just assorted chunks of (possible well-written) code tossed together because "that looks about right"?

No. Nobody thinks this, however a lot of people think that they can get away with this without anybody noticing (often they are wrong).

Originally posted by Zep
I would suggest that XP is the providence of the fly-by-night hacker who can produce reasonable code in coffee-fueled bursts, but has no idea of what a REAL COMMERCIAL product ACTUALLY looks like.

A large number of comercial prodcuts are written by hackers who produce reasonable code in coffee-fuled bursts. You probably use one to post to this board.

[ceptimus]

One of our programmers comments his code like this:

a += b; // add b to a

c = a; // take copy of a in c

for (e++ = b-- = d++ = f, c++; a < c && **f > b++; e[f[g[***h]]]++)
a ^= x[foo(&a, &b, &c, d, e, &f, g, &h)];

d = a; // store result in d

[jnelso99]

I haven't read the whole thread, but here is my experience with "extreme" programming:

First off, we didn't use all features of XP. The "two programmers at one computer" thing was the stupidest thing we've heard in a while. We did like:

- short development cycles of 2-3 weeks
- a potentially distributable app at the end of each cycle
- get a list of detailed "stories" (use cases) from the user (actually our product manager, who didn't really know what he was doing)

We basically broke up the use cases into manageable, distinct tasks, and set up a schedule for what gets done in each cycle, setting priorities for each task and guessing how long each task should take. The goal was to have a stable, buildable, and potentially releaseable application at the end of each cycle, whether the complete feature was done or not. Of course, we already had a "don't check code in if it doesn't build" rule (it's dumb to not have such a rule). This actually worked pretty well, because if we got our tasks done early, we could work on other, less important features of the app that weren't scheduled (provided we could actually get them done before the end of the cycle). We also used something we learned on "Star Trek" - figure out how long something will REALLY take, then multiply it by three, and use that number in the schedule. That way, when you get something done before that, you look like a god. I think Scotty said that in a Next Generation episode...

The main problem we had was that the guy who was supposed to give us the customers' use cases never really did, or at least in no detail whatsoever, no matter how much we pressed him. So we developers had to guess what the feature is REALLY supposed to do and how it would work, and we were actually right some of the time. Our VP of development never blamed us for when we got it wrong. He was the only cluefull one in management.

We (the developers) did pretty good, and actually got the app done when we said we would (actually, maybe a bit early). Management, however, were clueless and didn't know what to do with a finished app (what? Actually try to sell the thing? Nah - makes too much sense), so it was shelved. Not surprisingly, the company isn't around any more. I'm still a little bitter about that.

So all in all, I'm not sure how much of what we did was "Extreme Programming" (man, how we hated that term), but we did have a system that worked. I'm sure the right thing to do with any methodology is to just pick and choose what works for your situation.

Side note: In the computer gaming world, if a game has the word "extreme" in the title, most likely it really, really, really sucks.

[Zep]

jnelso99, that sounds pretty much like your "standard" project methodology, which, by the way, usually delivered good product on time under budget.

/personal_rant/
It was only with the introduction of overhyped supposedly "time/labour-saving" programming/project-building tools that the era of late and budget-blown-out projects started to occur more frequently. More time and money was spent trying to bend and warp the tool to fit the job, and frantically trying to patch the product right at the end. I should know; I have been around long enough to see it all happen this way...
/end_personal_rant/

[FutileJester]

Originally posted by ceptimus
One of our programmers comments his code like this:


:roll: Almost too true to be funny. Better not put me on the code review if that's gonna get dropped in front of me, I might not be responsible for my actions...

[FutileJester]

Basically almost everything XP advocates is an existing software engineering principle, taken to (you guessed it) an extreme. As such it's not a ridiculous idea, but I doubt it could be effectively put into practice in most company cultures. As with anything that pushes the envelope, some people adopt it as a religion and others (like me) try to see what bits make sense and can be pulled out of it.

Pair programming, for instance, is generally impractical. But we do sometimes use it for critical sections or code with a history of problems. After all, in these cases we're pretty much gonna have someone reviewing the code closely anyway; why wait until after it's written? It's a comparable man-hour commitment, but does things in parallel to shave schedule time.

Incidentally this is even easy to do remotely now. My partner and I are independent consultants, currently with one full-time client who doesn't need to see us in the office very often. So we're working out of our individual home offices with broadband connections. When necessary, we use Windows Messenger to app share one IDE to the other and talk through the code as we write it. Very effective, and we can work separately or 'paired' as much as the situation seems to warrant.

Another XP principle with some useful applications is to never write code without a test. I try to write tests, then write code, and catch a lot of bugs that way about a second and a half after I write them. This also helps solidify the requirements before committing to an implementation; if I can't write a test, I don't understand what it's supposed to do, so I'll take the time to clarify the requirement until I can write a good test. The problem here is that tool support for unit testing is still pretty simplistic at reasonable price points. If it takes too long to write unit tests, schedule pressures will force compromise here.

I'm willing to believe 100% XP might work in certain situations, but I'm skeptical without seeing some more convincing case studies. But in any case there are ideas worth looking at for the experienced engineer.

[jnelso99]

Originally posted by FutileJester
Pair programming, for instance, is generally impractical.

That, and we didn't really want someone else invading our personal space. We liked each other, but if we had to sit at the same computer for any length of time, we'd kill each other... :D

Originally posted by FutileJester
Another XP principle with some useful applications is to never write code without a test. I try to write tests, then write code, and catch a lot of bugs that way about a second and a half after I write them. This also helps solidify the requirements before committing to an implementation; if I can't write a test, I don't understand what it's supposed to do, so I'll take the time to clarify the requirement until I can write a good test. The problem here is that tool support for unit testing is still pretty simplistic at reasonable price points. If it takes too long to write unit tests, schedule pressures will force compromise here.

D'oh - completely forgot about this part of XP - We did try to do this as well. Our project was in Java, so there are unit test tools available. I agree with the "write tests first", because it helps document exactly what functions are expected to do in every conceivable situation. It also helps in creating the API and documentation (which our HR person ended up doing...). And I don't think there is much of a worry about test writing taking too long, because theoretically if the tests are complete, writing the actual code should be the easy part... ;)

So it sounds like we were doing "Semi-Extreme Programming", or maybe "Mild Programming"? :)

[peptoabysmal]

Originally posted by ceptimus
One of our programmers comments his code like this:

a += b; // add b to a

c = a; // take copy of a in c

for (e++ = b-- = d++ = f, c++; a < c && **f > b++; e[f[g[***h]]]++)
a ^= x[foo(&a, &b, &c, d, e, &f, g, &h)];

d = a; // store result in d

Now, that's funny, and true. I've seen source "example" code that was done like this as well. I think what it means that the programmer doesn't actually know what it does, but just plays with it until it outputs the desired result. Kind of gives me faith in the "millions of monkeys typing for millions of years could produce Shakespeare" idea.

:dl:

[a_unique_person]

"Use Cases". Why can't people just reuse ideas that were already invented. Isn't it good enough to reuse the wheel. There is no shame in that. "Use cases" has been known as other terms for years. WTF is up with these people. Do they really have to think that everything they think up is earth shatteringly new and that everyone else that has ever worked with computers is a neanderthal moron? What does "user requirements" miss out on?

I have worked with the IBM mainframe. I have cringed at people making jokes about messages such as "IKJEFT01 logon in progress". But guess what, every one of those messages was in a manual you could find, and it had more information on the reason the message was issued, and where to find more information on it. When you looked up the IBM problem database, the message number was the first thing to search on.

WTF is "Panic" about? There is no standardised error message system in Unix, or Windows. You have to hunt and peck on google and hope for the best.

[Major Billy]

Originally posted by Zep
XP appears to be incremental...
improve code reliability...
Code is written to meet todays requirements...
Programmer performance is measured with metrics...

REAL companies grew out of this mode of thinking about coding in the 1950's.

Just who are these REAL 1950's companies that apparently developed Software Engineering 30 years before the rest of the industry?

[Paul C. Anagnostopoulos]

I refuse to pay attention to any software engineering solution du jour until a double-blind study has been done with a medium to large application. Since that never happens, I have an easy time of it.

One of our programmers comments his code like this:
Looks to me like he grew up on assembly language.

I think what it means that the programmer doesn't actually know what it does, but just plays with it until it outputs the desired result.
I have a friend who claims that this is the way all programmers under age 40 work. Perhaps he's being a bit too sweeping with this claim.

~~ Paul

[Paul C. Anagnostopoulos]

AUP said:I have worked with the IBM mainframe. I have cringed at people making jokes about messages such as "IKJEFT01 logon in progress". But guess what, every one of those messages was in a manual you could find, and it had more information on the reason the message was issued, and where to find more information on it. When you looked up the IBM problem database, the message number was the first thing to search on.
Now, now, this is unfair. You know that manual was written back in the days when people thought they ought to write manuals about operating systems. Now it's all done with self-evident GUIs, so manuals are unnecessary. You're such a relic, AUP!

See that little question mark in the upper right? Click on it, then click on something you don't understand, say the label "Size of Buffer:". The popup blob will either say "no help for this item" or "enter the size of the buffer." What's the problem?

~~ Paul