Request for help - Agile / Xtreme programmers

[Clive Long]

There are a fair number of accomplished computer and systems engineers who contribute to this forum.

I have started (4 weeks late ) an Open University Course on software evolution.

One of the strands of the course is the abandonment of traditional, "structured" forms of systems development for a process that can accomodate rapid change and uncertainty.

I would like to (electronically) chat with people who use such "modern" methods and the benefits and challenges they bring. I have some dimensions I want to explore, such as quality, delivery dates etc. but I want to leave the discussion open to factors I may not have thought about.

If at all possible, I'd also like to communicate with non-technical people who have participated in the definition of or been on the receiving end of such software - and their assesment of what had been delivered.

My prejudice as I go into this is from the position of a Project Manager. I need deliverables, I need dates (when? , when? when?), I need quality, I need committed skilled resource. The title "Xtreme programming" makes me think of pasty faced adolescents who prefer to spend their time on surf-boards or snow-boards with trousers that hang round their knees rather than people who do "real" work. Help me confront and conquer my prejudice.

If you are happy to answer a few questions from me over the next 3 months - please PM me.

No commercially sensitive information will be requested nor disclosed to others by me.

Clive

[MartinHarper]

It's "Extreme programming", not "Xtreme programming". It's abbreviated to "XP", rather than "EP", which may be the source of your confusion. XP is just one example of an agile process.

If you are interested in quality, you may be interested to learn about Test First programming, which is a central part of the XP method.

[Lou]

Let me know how you get on, Clive. I'm pretty suspicious of it, particularly as it doesn't seem to concentrate much on obtaining the actual user/customer requirements (as a the big picture), as opposed to what they, and the spotty programmers (*spit*) think that they want.

Or maybe I'm just a disgruntled analyst...

[Minnie M]

I have been working (business and pleasure) with computers for over 25 years now although I am computer literate I am not technical in the true sense.

If I can be of help or you want to know the extent of my non-techy knowledge Clive, PM me

[bigdjiver]

Originally Posted by MartinHarper

It's "Extreme programming", not "Xtreme programming". It's abbreviated to "XP", rather than "EP", which may be the source of your confusion. XP is just one example of an agile process.

If you are interested in quality, you may be interested to learn about Test First programming, which is a central part of the XP method.

30 years back I was writing the test data first. 25 years back I was drafting the user manual and help files as my second task. It so helps to see the application from the user point of view.

Having lived through so many programming methods and philosophies I am tempted to view "agile" and "xtreme" programming as just the current fad, which is not to dismiss them as lacking merit. "Xtreme" (for "extreme") is in common use.

papers on effectiveness

[David Bailey]

Originally Posted by bigdjiver

30 years back I was writing the test data first. 25 years back I was drafting the user manual and help files as my second task. It so helps to see the application from the user point of view.

and

"Xtreme" - cue rant about trying to make developing sexy, grrr...

In my experience, the only way to get effective code development is to get effective code developers. Adopting a faddish programming method is about as effective as adopting a faddish business method. Anyone remember Business Process Re-engineering?

Of course, that still leaves the question of how to get effective code developers... But I think that's more a company-culture question than a programming-methods question.

Certainly, the most effective way to p*ss programmers off is to force them to adopt a new style of programming. If that helps

[Lou]

Originally Posted by DavidJames

and

Helps to see it from the user point of view? Helps?

***, it's essential, guys.

This is one of the things that I loathe about my current role as a technical architect. I sit in an office full of geeky nerdish guys, where we discuss/rant about the relative merits of Websphere, WebLogic, .Net et al. And we approach everything from the terms of technology.

No one ever stops to look at anything from the point of our customers. (Or if they do, its in terms of installations, response times, etc., never old fashioned stuff like usability).

Oooh! You've touched a nerve here! Sorry!

[Dreadful Scathe]

Originally Posted by Lou

Oooh! You've touched a nerve here! Sorry!

quite right Lou the fact that not enough time is spent considering the users needs is very apparant in a lot of applications and websites nowadays. The best rules Ive found is to get something that looks fantastic and lie about its backend to the managers but get something that still looks great but is fast and functional for the users. Thats your starting point then you have to sift through user comments for what they actually want so you can improve on it

[David Bailey]

Originally Posted by Dreadful Scathe

The best rules Ive found is to get something that looks fantastic and lie about its backend to the managers but get something that still looks great but is fast and functional for the users. Thats your starting point then you have to sift through user comments for what they actually want so you can improve on it

That sounds like the closest to An Ideal Process I've ever heard.

You should write a book about it - but you'll need a sexy title. Hmmm... "The DS method"?

[bigdjiver]

Originally Posted by Lou

Helps to see it from the user point of view? Helps?

***, it's essential, guys...

Behind most applications there is a "group of nerdy guys" who discuss endlessly the best way to deliver the ideal solution for the customer. Too many of us have seen the actuality that results.

When I first set out to write the user manual and help file first it actually forced me to consider what I was asking the user to do, finger press by finger press. A lot of people have been through a similar experience on this forum trying to describe a dance move. I have to confess that I have failed to understand the vast majority are describing after two or three read throughs.

The program I was working on was decoding drilling program files imported from paper tape. The competition asked ASCII/ EIA/ EBCIDIC? Metric/Imperial?Leading zeros suppressed/trailing zeros suppressed? Decimal point position? manufacturer format? and more...

Trying to explain just the meaning of those terms was a nightmare. Most of the time the user just received a disk and a diagram, and could not answer the questions even if they knew what they meant.

I ended up with a user manual that said click on the file. If it looks nothing like the diagram press this button once or twice until it does. If it too big press this key until it is the right size. If it is too small press that button. If none of this works our program does not understand that format yet - call us.

[Lou]

This has turned out to be a fun way of identifying personality traits....

Clive wants to know "when".
The Davids want to know "how".
DS wants to know "what".
I want to know "why".

Cute. *shrug*

[David Bailey]

Originally Posted by Lou

I want to know "why".

Thought you wanted to know "what foot"?

[Lou]

Originally Posted by DavidJames

Thought you wanted to know "what foot"?

Nah... am far more interested why it's better to be back on that foot. What's the benefits in doing it one way, rather than the other?

[bigdjiver]

Originally Posted by DavidJames

...
"Xtreme" - cue rant about trying to make developing sexy, grrr...

In my experience, the only way to get effective code development is to get effective code developers. Adopting a faddish programming method is about as effective as adopting a faddish business method. Anyone remember Business Process Re-engineering? ...

I worked for a leading software house which ran courses for senior programmers and analysts. I worked on a new course which was basically a rip-off of Yourdon, Weinberg et al , rejigging and renaming their key concepts. I was so disgusted at this faddish process that I asked for my name to be removed from the credits. I did later run into a senior programmer from ICI who said that it was the best course that he had ever done. Sometimes hype does have something to back it.

My first experience of programming development methodology was to attend the first public lecture given by Michael Jackson, (not that one) on structured programming (JSP). That was the single most valuable event in my programming career, and using that methodology got me the job developing that course. I was pleased to see his name associated with Agile and Xtreme.

Methodologies can make a difference. One coding contract I had was estimated to take 8 months, but I was given 6 months to do it. After three months I had not written a single line of code for the program, but had spent that time redesigning the program using JSP (not what I was there for!) and creating the test data. I finished on time, with only two errors found in several thousand lines of code. (one punch girl error, a total one column out of alignment.)

[David Bailey]

Originally Posted by bigdjiver

Methodologies can make a difference.

Sure, and I'd never say "don't have a methodology" (and neither would you I guess), just "Fad methodologies - grrr".

[David Bailey]

Just thought I'd share this:

A product one of my team has spent 3 months documenting has now been radically changed - nothing new there. But, the only reason we know this is because the customer (no, not the developers in our company, that'd be way too sensible) told us directly about the changes. Grrr.

I then confront the people responsible, only to be told that "it's only minor changes to the interface, no major functionality changes, the user guide needn't change much". Grrr Grrr.

I then spend, oooh, 30 minutes on the phone trying to explain that, to the user, interface changes are actually quite important functionality, and that it probably helps in a user guide if the screenshot matches the, you know, screen they're looking at...? Grrrrr X many

Whew, I feel better now.

[Clive Long]

Originally Posted by DavidJames

<< snip >>
I then confront the people responsible, only to be told that "it's only minor changes to the interface, no major functionality changes, the user guide needn't change much". Grrr Grrr.
<< snip >>
Whew, I feel better now.

Impact assessment

Change control.

That'll bring 'em back into line

No it's never worked for me either.

Wanna fill in a questionnaire?

CRL