It is at least shit covered in glitter, so maybe it’ll be the glitter that rains down on me, not the shit.

AB

1) Talk to the users and gather business-, process- and workflow-requirements
2) Re-engineer the fucking processes ok?
3) Make it easy to use

This is a to-do list in order of importance not an options list.

Unfortunately this project seems to think that they can replace all of the above with (4) make it pretty. If it’s pretty, you see, we won’t notice it’s shite until it’s too late. As it was described to me today “it’ll be a turd covered in glitter”.

This is a project in need of:

1) A sponsor
2) Money
3) A steering group (not just a list of “workshop attendees”)
4) Documented requirements (not just a list of “outputs” from the “workshops”)
5) A functional spec (not just a series of paintshopped “screenshots”)
6) A technical spec (any fucking technical spec – the one for designing the hovercraft would be better than nothing)
7) Someone, anyone, with balls and integrity.
A great big banner saying “It’s the processes, Fuckwit. It’s not the front end It’s the frigging PROCESSES.”

We can’t talk to them, because they have already gathered their requirements, (a year a-fucking-go), and they’ve been signed off (by the previous project manager’s mother, her hairdresser and her ickle wickle puddy cat so far as I can make out). We can’t actually – like see the requirements. Oh no. They know what the requirements are. They’ve been signed off. What do we know? We’re just users. And here we go round in circles again.

The fact that we have a Great Big Hairy Dependency and represent 35,000 users is irrelevent. They have their fingers stuck in their ears, their eyes are screwed shut, and they are singing “la la la la la” at the top of their pathetic little voices.

But it’s ok. I shouldn’t be worried, and I shouldn’t be nasty.

They did workshops. It’ll all be fine…..

Thank you.

Aphra.

The same point was made by Alex Papadimoulis
“[...]Instead of realizing that the first applications they wrote were poorly designed, poorly programmed, and soon-to-be failure – like everyone’s first are – they chalked them off as a success and moved on to the next project. They developed more software. Bigger software. More expensive software. Wrong software. All because they kept thinking that the completion of the project meant that it was a success.

Had they simply admitted to earlier failure – and learned from it – they would have never created such an epic disaster. By imagining that their past projects were a success, they had done far worse than failure.
”
http://worsethanfailure.com/Articles/What_Could_Possibly_Be_Worse_Than_Failure_0×3f_.aspx

That brings me to the second advice of the book “The Pragmatic Programmer” : Think about your work. If you don’t think about what you’re doing and more particulary what you’re doing wrong then you can’t improve.

That’s why I tend to be pessimist. I start from the principle that I suck, that what I do equally suck and that what i’m doing is going to fail. That forces me to improve what I’m doing constantly. It also has the nice side effect that things generally turn out better than anticipated .