Sign off my IT project or I’ll PHONE your MUM When you have to go, you have to go. And when you do, don’t rush it otherwise you can end up with damp socks… as my father-in-law discovered during a hurried slash-and-dash in a not-so-lonely lay-by one night. I might revisit that particular anecdote later. For the moment, I invite you to consider what the computer has brought …
The Governator did one too, it is well worth a look: http://images.huffingtonpost.com/gen/114612/original.jpg
I have left the more important points, special attention to: 14, 18 and 19
3. I have challenged the entire ISO-9000 review team to a round of Bat-Leth practice on the holodeck. They will not concern us again.
5. Defensive programming? Never! Klingon programs are always offensive. Yes, offensive programming is what we do best.
6. Klingon programs don't do accountancy. For that, you need a Ferengi programmer.
7. Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM.
9. By filing this bug you have questioned my family honour. Prepare to die!
10. I am without honour...my children are without honour... My father coded at the Battle of Kittimer...and...and...he... HE ALLOWED HIMSELF TO BE MICROMANAGED. <Shudder>
11. You question the worthiness of my code?! I should kill you where you stand!
13. Specs are for the weak and timid!
14. Klingons do not believe in indentation - except perhaps in the skulls of their project managers.
16. Klingons do not "release" software. Klingon software escapes, leaving a bloody trail of design engineers and quality assurance testers in its wake.
17. Debugging? Klingons do not debug. Bugs are good for building up character in the user!
18. As for project orders (requirements, goals): Klingons do not deliver; we EXECUTE. For the glory of the empire!
19. Perhaps it IS a good day to die! I say we ship it!
And the result is:
Qapla [also Kapla from the Klingon language: meaning "success" (or sometimes "absence of failure")]
You have made many enquiries about User Acceptance Testing. There will, of course, be User Acceptance Testing. When the software is ready and it has escaped from the development team, it will find you and it will test you, mercilessly. If it finds that you are worthy and acceptable, it will install itself on your computers. Do NOT try to interfere with that process, unless you wish to suffer serioius injury and possibly death.
The right question is:
I can see that you are resource constrained and do not have enough resources for your current project workload. Would you like me to escalate it so you can get some additional resource?
It sounds polite, it looks innocuous and at the same time it is clear that the escalation may be "she is incapable of doing her job due to overload, remove some of her responsibilities". She also cannot take you to the task for threatening her as it does not look like you are. You can also smile appropriately just to make sure she got your point.
coming from the users side here, I'd love to see some UAT rather than just the crap that gets foisted onto us.
For you developers though, seems like the solution is easy, sign here to accept you refused the opportunity to feed back on the project, and any futrther changes that could have been picked up will be paid for (at a markup) by the users.
I've performed numerous UATs in formal circumstances on behalf of the user. On one side you get the supplier trying to pull the wool over your eyes and whispering to your higher level management that you're not up to the job or, even worse, you're being 'unreasonable'. On the other side, you get your own higher management blaming you if it doesn't pass because of 'minor and easily fixed' shortfalls. All this with a printed and agreed UAT procedure that has been available for weeks. Your immediate manager is sympathetic to you but he is under pressure too and so he slides the blame onto you - in a kind and regretful way.
It's not a job for anyone with a heart or a soul.
This post has been deleted by its author
Who does the UAT and also when? That's the question.
A few years back a great chunk of my time was spent sitting with the manager who had done the UAT work on a major data sharing system that we were all meant to be using, because it was pretty well unusable.Trying to show her how it should have been set up to work. So that she could then go back to the developers to get it sorted out. It was a clumsy design, poorly implemented and mostly unusable. Things like, if the user paused for even a few seconds the screen they were working on closed ( for security) and the data was lost. Or navigating to different parts was a bit like playing Myst. ( But without the graphics).
The thing is, she'd headed up the team that briefed the system designers and tried the system out, but had never approached any ordinary users. let alone the external client groups who'd be providing the bulk of the information. God knows what the designers thought they were meant to be doing and how much of the mess was theirs and how much was hers. But as a clue, the system only worked with IE 6 - already obsolete by then.
Wrote:- "[the manager] headed up the team that briefed the system designers and tried the system out, but had never approached any ordinary users
and:- Trying to show [the manager] how it should have been set up to work. So that she could then go back to the developers to get it sorted out"
We had a similar thing. Our manager and IT dept gave a spec for a paper-flow system to a contractor without consulting us users. We were strictly forbidden to say anything more than "Good morning" to the contractor who was working on our site for two months, and returning afterwards to the contractor to address the glaring shortcomings or even to debug was totally out of the question.
The reason given by management is that every time one of us were to open our mouths about how it should be done, the contractor would have added another £n000 to the bill as a "varation".
The saddest part was that we previously had a perfectly good working system using Paradox and WordPerfect, created by someone (a civil engineer, not an IT guy) in our own branch. Him being just there also had the advantage that he would implement any changes needed as time went on. But we had to ditch it because management wanted an all-Microsoft shop, and moreover wanted to ban any in-house coding on the assumption that it could not be any good.
"Your immediate manager is sympathetic to you but he is under pressure too and so he slides the blame onto you - in a kind and regretful way." That's a dangerous way to live. You may end up with a sudden transfer to Antarctica and an appointment with the lowest quality dentist, cost cutting don'tcha know, to have all your mental fillings replaced forthwith as you'll be 'wintering over.' (Don't mess with the best.)
Strange but I always liked spending a week with the users tweaking the design in. They're the people that'll be using it and, in my mind (a truly scary place) improves buy-in. They 'own' it. Cuts down on support calls but you make that up in feature requests.
On one side you get the supplier trying to pull the wool over your eyes and whispering to your higher level management that you're not up to the job or, even worse, you're being 'unreasonable'. On the other side, you get your own higher management blaming you if it doesn't pass because of 'minor and easily fixed' shortfalls
It's a game. A nasty, brutal, sociopathic game, but a game nonetheless.
Wherever you fit in the hierarchy, your job is to regulate pressure. You need to apply pressure downwards, into your own workload (and your underlings, if you're lucky enough to have any). But more importantly, you also need to apply it upwards to your own managers. If you don't tell them that the job is impossible and you need more something, they'll assume everything is fine. And if you don't tell them this on a daily basis, they'll assume that whatever you were complaining about yesterday is all sorted and they don't have to worry about it any more.
If your management is going to "blame" you for failing the software based on "minor and easily fixed shortfalls", then you don't really have signoff authority, and you need to explicitly delegate that authority (always upwards). Present your manager - daily, or weekly, whatever they'll tolerate - with a summary of all outstanding and resolved defects. (If you're feeling helpful, you could do some mathematical modelling and predict how long it will take to get the software into a state that meets the predefined UAT criteria, but that's risky, 'cuz you'll be held responsible for it.) But make it clear that you are prepared to continue testing at this rate until (a) your retirement, (b) the end of the world, or (c) the UAT criteria are fulfilled, whichever happens first, unless s/he - your manager - tells you to stop.
And when she does tell you to stop (or gives you another assignment, which is the same thing) - bingo, there's your signoff.
It's not always the UATers being lazy/busy.
I've been on the wrong end of too many UAT's that appear to have completely skipped all the previous testing that's supposed to happen. I.e. I spot an issue in 10 seconds then have to waste an hour documenting it and speaking to the devs on the phone. All this without any UAT process/documentation to hand. Oh, you don't need to do any of that, just send us an email saying it's OK. Er, NO, this is EXACTLY why the last 5 releases went to shit. You need your begrudging testers to follow a step by step test process with multiple scenarios because, as mr dabbs says, they don't give a toss; not spend 5 mins tinkering then go sod it, I'm off home "it's fine". It isn't.
I'd guesstimate that a good 70% of UAT is done by people who will never actually use what they are testing, don't bother doing any testing and just sign it off. Of the 30% that do, because they are given no guidance they do a crap job and miss problems.
The last time I, er, shed some weight at work, the bloke in the stall next to me's phone rang - and he answered it.
Queue a raft of deafening farts, coughs, grunts, newspaper ruffling, spits and flushing from the various stalls so it was more than obvious where he was taking the call.
What's that expression? Hive mind?
I thought I had written a rather good call logging system to use for our service department. I thought I would know the most important information that should be logged so that I could assign the correct engineers to deal with the customers faults. I though the MD would be happy that I saved us over 6K plus ongoing costs by not purchasing an off the shelf system. I thought I ran the department ?
Engineers have been using it for several weeks, just for addresses to start with now they can close calls with a customer signature on their phones...... so whats wrong with it ? Turns out that I hadn't argued enough for the budget and he would have signed it off if I had kept pestering him grrrrrrrrrrrrrrr.
Ever have that feeling that using initiative is sometimes not worth the effort ? He doesn't even have to use the bloody thing but apparently it's not pretty enough ffs
Awesome article, Yours are some of the best that I read on the reg.
Many years ago I was pressed into service by the development team to get a customer to sign off an overdue UAT. A train to almost Land's End for an overnight stay. Early morning taxi to the customer in the middle of a cold and wet nowhere. Several cups of coffee with much patient waiting for the customer to get themselves organised. Finally a few minutes successfully running the acceptance test. Then taxi and trains back to home by the evening.
Two days later a repeat performance - this time an overnight stay in Scotland but fortunately not John O'Groats. At least there was the compensation of buying a bottle of Tormore single malt at Glasgow station while changing trains on the return leg.
It could have been worse - the project manager wanted me to use a hire car rather than trains and taxis.
If your users aren't motivated to get their hands on the software and try it out, maybe you're making the same mistake 95% of IT operations do. It's your job to supply what the user wants so that it will make his job easier, not try to foist stuff on him just because it suits your own purposes.
Do you remember the prediction in the late-1970s that by the turn of the century we will have entered a push-button age? Apparently, computers and robots would take over all our hard work and society would be struggling to deal with all the leisure time with which we’d be left to endure.
Leisure time? I don’t think so. Even by Tomorrow’s World standards, this prediction turned out to be a real turkey.
Alistair, I was helping this stuff happen back then. We just used the wrong words like "leisure time". The correct ones were "necessary structural unemployment", or "labour is too expensive, even when it comes from low-cost countries". The exception is for people with the required skills who we will work even harder.
Have you noticed that C18th capitalism is making a return? The idea seems to be that businesses should have fungibility of their workforces - If they can't be automated.
Beancounters
Between the 1970s and the 1990s the accountants took over the world. And to them staff are just bits of machinery. SO if they can be made more productive with real machinery you just get rid of a few, you certainly don't reduce their hours.
And yes, the attitude is essentially 18th C mill owner, but with a fancy certificate.
int main(enter the void)... The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
