A long time ago on a project far far away, I saw something that gave me food for thought. Following an initial baseline performance test, the project was in a tuning cycle, with some very bright performance engineers doing everything they could to drag the application at least somewhere near the performance targets.
The performance requirements they were trying to meet weren’t unreasonable. They were building a replacement system that was almost functionally equivalent to the system it was replacing, and the requirements had been taken from a baseline test of the old system.
As the tuning progressed, the lead developer from one of the system areas had been keeping a spreadsheet tracking the improvements that were made to the response times for each step of the key business processes. I put this down to him being very conscientious, and gave it no further thought…
…until one morning I came into work and some of the biggest performance defects were closed – a comment in each defect said “accepted by the Business”.
Response times were nowhere near the requirements, so I was sure that the lead developer must have used the Force (or was holding someone’s dog to ransom or something).
But it turns out that he just had a much better understanding of human psychology than he did of performance tuning.
In his pop-psycology book Influence: The Psychology of Persuasion, Robert Cialdini explains:
The general rule says that a person who acts in a certain way toward us is entitled to a similar return action…one consequence of the rule is an obligation to repay favours we have received. Another consequence of the rule is an obligation to make a concession to someone who has made a concession to us.
So by using his spreadsheet to show that the performance had improved significantly, the developer put the business owner in a position where he felt obliged to meet the developer “half way” and accept response times that were four times what he had originally asked for (even thought there was still three months to go before Go Live).
I’m sure it was just a trick of the light that made the umbrella handle poking out of his bag look suspiciously like a lightsaber.
Related Posts
4 Comments
Comments are closed.
These aren’t the defects you are looking for…..
Yep, much catchier.
CCAL Ninth Rule of Testing: When “Accepted by the Business” is used to close defects, you know for a fact that many long overtime testing shifts are coming soon.
The CRUNCH always occurs at testing. Development gets behind…. code is not delivered on time…. defects abound…. development can’t keep up…. red flags start to raise…. implementation is threatened…. execs vow to “keep on schedule”…. development needs to cover their hineys…. the business is under pressure…. “Ok, we’ll go with what we have and fix the rest in place”….
Mean while, the testers are doing the best they can just to get any test cases or scripts to run while everyone jacks with the testing environment, rolling new code every hour, and oh yes……. let’s just go into 24 hour mode and test around the clock. Uh, yes…. that’s the ticket.
Good grief. When will they ever learn.
Nice article. Sadly this way of showing effort works well even if it does result in useless crap.
A side effect of this behavior working so well is that the team leaders tend to spend time on a lot of otherwise meaningless small improvements without showing any interest of going to the bottom of the problem.
While solving the problem with erratic small changes would be a lot more work than a straightforward solution most likely a lot fewer small changes are needed to job approved regardless of the result being sufficient or not.
At his point chances are very good you in one of the 80% miraculously failing projects.