Six Impossible Things Before Breakfast

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.]