Reply to: RFCs, test findings and socially disabled ICT people

[doodab]

and thats the key isn't it.

Is the most important part delivering a software package that works or ensuring the project is delivered to (estimated) timescales and (estimated) costs

obvious when you think about it but unfortunately we live in a world where dick ed's generally rule....

And oddly they aren't usually the people that write the software or the ones that have to use it.

Although personally I would blame a system that fails to allow for human weakness rather than the individuals themselves.

[original PM]

In the long run, you may be right, but it won't make the project late and over budget.

and thats the key isn't it.

Is the most important part delivering a software package that works or ensuring the project is delivered to (estimated) timescales and (estimated) costs

obvious when you think about it but unfortunately we live in a world where dick ed's generally rule....

[doodab]

Not fixing stuff costs more.

In the long run, you may be right, but it won't make the project late and over budget.

[SupremeSpod]

Ah, but your last line sums up why all this is a load of bollox. We're all going to be paid anyway.

[Mich the Tester]

Show me signed customer approval and you can have your changes. I'll drop what I'm currently working on. Btw, after the changes, we'll have to perform our unit testing again, ensure that our version numbers are updated in the read-me file, rebaseline the code. Deliver to Integration, they'll have to perform full regression testing.

And after all that when you or any other self-righteous f**ker who reckons it'll take "only a couple of minutes" to change back we'll do it all again.

Hey, happy invoicing everyone.

Ah, but your last line sums up why all this is a load of bollox. We're all going to be paid anyway.

[NickFitz]

Oh well, shall send an invoice for telling my tester not to bother discussing the merits of a minor adjustment to a sentence.

The other year I worked on an online voting system for some music awards where a minor, last-minute change to one sentence caused about 30% of users to enter their votes in the "Other" field, rather than selecting their chosen candidate directly. As the general public can't spell to save their lives (quite a few of them spelt "Mika" incorrectly, ffs) it wasn't practical to detect this automagically, so somebody had to manually check thousands of votes and allocate them to the correct artist, all against a very tight deadline.

Poetic justice: that somebody was the person who had changed the sentence

[SupremeSpod]

Not fixing stuff costs more. The system is supposed to provide a return on investment; anything that gets in the way of that is very expensive. Yes, the builder wants to know he'll be paid for changes, but I'm talking about a collection of cosmetic issues that would take no more than a few hours to solve, but which would create the goodwill needed for the acceptant to sign off while accepting workarounds for some more serious issues. It's childishness on both sides and I'm trying not to get involved.

Show me signed customer approval and you can have your changes. I'll drop what I'm currently working on. Btw, after the changes, we'll have to perform our unit testing again, ensure that our version numbers are updated in the read-me file, rebaseline the code. Deliver to Integration, they'll have to perform full regression testing.

And after all that when you or any other self-righteous f**ker who reckons it'll take "only a couple of minutes" to change back we'll do it all again.

Hey, happy invoicing everyone.

[Mich the Tester]

Fixing stuff usually takes time and costs money, so it's a question of who gets blamed for the project being late and going over budget.

Not fixing stuff costs more. The system is supposed to provide a return on investment; anything that gets in the way of that is very expensive. Yes, the builder wants to know he'll be paid for changes, but I'm talking about a collection of cosmetic issues that would take no more than a few hours to solve, but which would create the goodwill needed for the acceptant to sign off while accepting workarounds for some more serious issues. It's childishness on both sides and I'm trying not to get involved.

[doodab]

What does always confuse me is why as Mich says there seems to have to be big discsusions around whether it is a bug, change or whatever - the fact is the software is not meeting required standard so sort it out.

Obviously this wouild all work fine if it wasn't for pointless fu<kwits playing stupid games.

Probably won't work overly well with external developers either.

Fixing stuff usually takes time and costs money, so it's a question of who gets blamed for the project being late and going over budget.

[SupremeSpod]

I'm glad you feel better; that's what a good rant is for. Sex is better though.

Anyway, I take your point and can recognise a lot of what you're saying. However, documenting user requirements and designing for ease of use is not simply about asking users to participate; a good designer will actually advise users on what is possible or workable on the basis of experience. In reality, the 'designer' is often a tool monkey or worse still a SAP/Siebel/Peoplesoft/Oracle/<insert other brandname> 'consultant' who can't picture the world in terms unknown within his narrow understanding of his chosen software package.

Don't confuse "Designers" with "Developers"...

[original PM]

ah yes - I spend a lot of time designing software etc for our internal developers and it is true that the users often put little to no effort in - but the thing is that is how it has always worked mainly because the users also have a day job - which normally takes up most of the time.

Rarely do you find users of a system have time to down tools and sit mulling over screen designs etc. Thing is I have never come across any business where user have any time and yet whenever you get new project manager bod in there seems to be some confusion over this.

Anyway to get to the point finally with our internal developers we make sure we deliver what is agreed initially and then if things need changing - well they get changed be it a cosmetic change which enhances useability or a changes reuqired to make the system work. Obviously we have a limit and do not go stupid on allowing all teeny tiny changes go through but in general we try and meet the users needs.

What does always confuse me is why as Mich says there seems to have to be big discsusions around whether it is a bug, change or whatever - the fact is the software is not meeting required standard so sort it out.

Obviously this wouild all work fine if it wasn't for pointless fu<kwits playing stupid games.

Probably won't work overly well with external developers either.

But hey so what

[doodab]

I'm glad you feel better; that's what a good rant is for. Sex is better though.

I prefer drinking to shagging when I'm in a bad mood, but each to their own.

[Zippy]

Keep it up lads - this is like being at work. Now don't get me started on Bob ...

[Mich the Tester]

We know what users wants. Mostly, they want to do **** all and have us read their minds.

It often turns out that these are things that could have been spotted earlier and remedied fairly easily if the users had actually bothered to participate in the requirements & testing process when they were initially asked and for the full period instead of giving it two hours effort at the last possible moment.

Because of this, if you don't maintain a strict distinction between bugs and changes, you end up with more and more small changes classified as bugs, which eventually adds up quite a lot of work that has to be done twice, and the main reason it has to be done twice is because the users were too ******* lazy to get their arses in gear in the first place.

Understanding peoples needs and giving them what they want works both ways. If you make people's lives harder because you can't be bothered to do what they have asked you to do when they asked you to do it you can hardly complain when they return the favour.

(I feel much better now)

I'm glad you feel better; that's what a good rant is for. Sex is better though.

Anyway, I take your point and can recognise a lot of what you're saying. However, documenting user requirements and designing for ease of use is not simply about asking users to participate; a good designer will actually advise users on what is possible or workable on the basis of experience. In reality, the 'designer' is often a tool monkey or worse still a SAP/Siebel/Peoplesoft/Oracle/<insert other brandname> 'consultant' who can't picture the world in terms unknown within his narrow understanding of his chosen software package.

[doodab]

Anyway, I see all this and think to myself ‘isn’t this all a bit sad?’ What’s the chance that said dev team leader would actually bother with this kind of discussion if he had a healthy sex life? Isn’t all this tosh just evidence of the lack of social skills and empathy that makes so many ICT people unable to comprehend what a user actually wants?

We know what users wants. Mostly, they want to do **** all and have us read their minds.

It often turns out that these are things that could have been spotted earlier and remedied fairly easily if the users had actually bothered to participate in the requirements & testing process when they were initially asked and for the full period instead of giving it two hours effort at the last possible moment.

Because of this, if you don't maintain a strict distinction between bugs and changes, you end up with more and more small changes classified as bugs, which eventually adds up quite a lot of work that has to be done twice, and the main reason it has to be done twice is because the users were too ******* lazy to get their arses in gear in the first place.

Understanding peoples needs and giving them what they want works both ways. If you make people's lives harder because you can't be bothered to do what they have asked you to do when they asked you to do it you can hardly complain when they return the favour.

(I feel much better now)