View Full Version : Extreme programming

10th November 2003, 06:05 AM
Just out of interest just come across this software methodology:


Which mostly strikes me as crap :D but might be of interest.

Personally I believe in unconventional methodologies as I think all the accepted ones I have used are based on totally non real world assumptions. I think most real software projects for real customers are inherently far more dynamic than the official methodologies I have seen deal with.

For example.

1) In the world of GUI's the interface is king and a solution to a customers requirement whcih would ordinarily be designed around their existing methods of working may not be best. A solution that has the clearest interface and thus changes their methods may be far better. But this is a learning curve and no amount of people talking around a table may come up with the answer. Thus prototyping is often essential and most methodologies do not allow for this.

2) Most methodologies assume distinct phazes, requirements, design, programming, testing... with often more divisions. But due to the dynamic nature of software projects this is artificial, bits of a project will be at different stages at different times. Existing methodologies tend to end up with thick wads of paper signed off for the complete project at each stage. The target becomes the signing off of each phaze and not the project itself. I was working for a big "quality" orinetated company once and was given one of these wedges of paper to start the programming with and had to turn round and say that I had no idea what to do :( I was gently pointed to the design of the previous version of the software and told to use both documents :rolleyes: The other flaw with the stage approach is that it allows and encourages real problems issues in the design to be glossed over with waffle, allowing the shit ot hit the fan in the next phaze.

I prefer a far more complex appoach where the top level design is done fairly conventionally and a project is divided into modules that fall into catergories.

a) Straightforward modules we know we need and which can possibly even be coded now. They may need to be "over-engineered" as some of the interfaces to the rest of the project may not be defined yet.
b) Speculative modules that fit a prototyping approach. e.g. the interface and possible some proof of concept/critical areas.
c) Need further thought modules. We know we need these and we know we can code them, so it is safe to delay finalising design. Feedback from other modules and simply waiting until we are up the learning curve will make postponing decisions here a good idea.
d) Critical modules. These are the ones that normally get glossed over. We know we need them and we know the project will succeed or fail unless they work and are got right. Whilst we can work in parrallel on a-b-c-d these are the modules that we constantly return to and do not let slip. Or more to the point we may be getting on with some programming on easier stuff as no one in my experience can sit round a table in meeting and definately come up with the answer to the critical stuff. But the critical stuff is constantly the focus of the agenda and work.


27th November 2003, 05:21 AM
/spec breezes by

"Post as article?"

/spec disappears into distance...

1st December 2003, 03:14 PM
I must admit I really don't use one type of methodology. I look at each project as,
1. Why am I here
2. What do they need
3. The best way to do it (and normally the cheapest)
4. Estimate the time needed + 2 weeks
5. Try to use open standards.
6. Document the thing!

But each man to his own ;)

1st December 2003, 03:22 PM
I certainly agree that methods need to be flexible, there are just so many variables in a computer programming project that a one size fits all approach is doomed to sillyness :D

But equally some type of methodology is needed on a larger project with more people and customers involved. With the best will in the world your number 1,2 & 3 can start looping somewhat :D and methodologies are often useful in managing this process.


1st December 2003, 11:36 PM
lol, ain't that the truth, but you can always dream ;)