As an accompaniment to my June 2011 Tea-time with Testers article, "Six Impossible Things Before Breakfast", here is the list of lies I have heard on software projects over the years. I’ve grouped them roughly; arguably there are some lies listed that cross categories. Also, there is some overlap. “We have to get creative about these numbers!” is one variation on falsifying progress and status.
I invite you to add lies you've heard to my list. I'd love to hear about your experiences and observations of software project lying, and also of truth-telling in difficult project circumstances. Please leave a comment.
As a reminder, here are the parameters I set for my list.
I had personally to have heard the lie told one or more times. Each lie or category of lies had to be material to a software project, though it could have been told to make a sale before a project began or to describe a project after its end. Each lie had to be relatively common in the industry—or at least not rare. A lie had also to be significant to a project: to have influenced perceptions and/or decisions. And finally, I excluded malicious lies intended to subvert or sabotage an individual on a project.
Lies told to make a sale or get funding for a project
1. Deliberate underbidding [but we’ll make it up with change requests]
2. Bait & switch [proposing highly skilled staff to make the sale, then replacing them on the project with junior and lower-skilled people]
3. “The system will be standalone.” [To be usable, this particular system actually required expensive integration with several major systems, both upstream and downstream. The development team told management this before the project was approved, but the project sponsor ignored their information. I’ve heard similar claims on other projects.]
Management lies
4. Fictitious schedule: fixing scope, cost and staffing after arbitrarily slashing informed estimates by the project teams
5. “Our software is bug-free.”
6. “We can cut the testing in half without affecting quality.”
7. “This project is life or death for the company. If it doesn’t succeed, we’ll all be out of a job!”
8. “We’re slipping the date out, but don’t tell the team. We need to keep their feet to the fire.”
9. “We have to get creative about these numbers!”
10. “We can solve all the project’s problems with mandatory overtime.”
11. “The project team is pulling out all the stops to deliver this project.” [Actually, they’re exhausted and making a lot of mistakes, and we’re only getting about 30 hours productivity from the 60-hour weeks we’re making them work.]
Lies about programming
12. Code complete. [On one project, the programmers had actually left comments in the code listing what had not yet been done.]
13. “We’re done!” [Though we haven’t done the unit testing we committed to.]
14. “I only changed one line of code. You don’t need to test it.” [Though I didn’t do an impact analysis of the fix and I have no idea what might break.]
15. Padding estimates
16. Hiding bugs
17. “It’s not technically possible to do it that way.” [It is, actually, but I want to use this cool new technology that will enhance my skills.]
Lies about testing
18. “Anyone can test. We can get people off the street to do this job.”
19. “Anyone can test. We just have to give them the right process to follow.”
20. Tester exaggerating risk
21. Tester padding estimates
22. “This bug is out of my scope, and I’m under the gun. I don’t need to report it.”
23. “Testing is holding up the project. You’re finding too many bugs!”
24. “Our test cases will provide complete system coverage.”
25. “The infrastructure upgrade will be completely transparent. You won’t need to test.” [Although nobody did an impact analysis of the upgrade and we have no idea what might break.]
26. “We can deem these test cases passed.” [Though they haven’t actually been executed for months and we strongly suspect many of them wouldn’t pass.]
27. “You only need three weeks for testing.” [Because the code is late and we cut three weeks from the test schedule.]
28. “The testers don’t know what they’re doing.” [They estimated it would take two weeks, but found incomplete code and so many bugs it has taken six, and they’re not done yet.]
29. “Our mature test process employs all the industry best practices.” [Major bugs frequently bring production systems down, but we have all the “right” testing documentation.]
30. “Total test automation will make testing much faster and more efficient, and we can save on expensive labor costs.” [We haven’t thought about who will design or script the automated tests, and we have no idea what it will take to maintain them.]
Lies told by customers
31. Exaggerating the risk of bugs to make a vendor or internal IT team look bad
32. Lying about their own state of preparedness
33. Falsely claiming a vendor’s solution was not technically viable [Customer’s IT had failed in two attempts to develop the system and didn’t want the vendor to succeed and show them up. I've seen variants of this elsewhere.]
Miscellaneous lies (anybody)
34. “We’re a month behind, but it won’t impact the schedule. We can make up the time!”
35. Knowingly committing to impossible deliveries
36. Deliberately downgrading bug severity to make a release
37. Falsely blaming slow progress on hold-ups by other teams or external vendors
38. Falsifying progress and status to look good
39. “Our security rules don’t permit you to have that access.” [Not true, but it’s a lot of work to give it to you, and I’m too busy/lazy.]
Subscribe to:
Post Comments (Atom)
4 comments:
Great list!
One of my favorites is related to 17. In this case, the programmer maintains that something is impossible to do in the new technology, because it is possible but boring, assuming that I won't know if it is possible. I now have friends I can ask what can be done in new technologies.
"That's what the customer asked for, so that's what we'll give them."
Meaning either "the customer didn't understand the implications and overlooked something complicated" or "we know that they expect something & they assumed it was so obvious they didn't need to specify it - more fool them".
Whatever, the consequence is "we'll pretend it's not required then hit them with a change request & rescheduling when they eventually do notice, which will give us some more revenue and buy us some more time".
And my personal bugbear.
"We're passionate about software quality"
Which pretty much means, "sure, software quality's important, but in the grand scheme of things it's way behind the quality of the coffee though still ahead of the interior decoration, maybe".
The puzzling thing about these attitudes is that people don't want to face the screamingly obvious fact that lying corrodes trust and means clients end up assuming everything we tell them is suspect. Telling the truth is the bedrock of a long term, profitable relationship. The truth is a competitive advantage - which is a rather sad and ridiculous state of affairs.
What's the one thing that always gets cut if sales are looking for ways to bring the price down for the customer? Testing. I've been on so many projects where testing has had very little or even zero time officially allocated to it, and then PMs are surprised when deadlines slip...
I heard this recently during a major commercial product upgrade. 'We're not testing the 'out of the box' features' ‘....
Stephen
Post a Comment