ProgrammerExcuses

From Epowiki

Jump to: navigation, search

Programmer Excuses


  1. That's weird, It's never done that before
  2. It worked yesterday.
  3. It works on my machine.
  4. It's too complicated for you to understand.
  5. It can't be done.
  6. Probably a hardware problem.
  7. Somebody must have changed my code.
  8. Even though it doesn't work, what it doing ?
  9. Why do you want to do it that way ?
  10. I only changed a comment.
  11. I figured I didn't need to test because it was obviously correct.
  12. The code doesn't need comments because it's self-documenting.
  13. Maybe it's static.
  14. Oh dear, it must have run out of electrons again.
  15. It works for everyone else, so it must be your fault.
  16. Its a Microsoft bug.
  17. The processor stack spring has worn out.
  18. Loop fatigue.
  19. What did you expect? They made it out of foobar.
  20. Shiftless Registers.
  21. The bit-bucket's full.
  22. This 3rd party library is very buggy.
  23. The compiler screwed up.
  24. We're running out of memory.
  25. For this we really need something faster.
  26. I suspect it's a bus collision.
  27. They changed the protocol.
  28. Apperently they compiled it for the wrong target.
  29. If I wanted it next week, I'd have asked for it next week.
  30. Your GIZMO needs the latest copy of Windows which has the appropriate driver. Or your old gizmo is not supported any more you will need a new gizmo for which you will require the latest copy of windows, Sorry your old software will not run the new gizmo under the latest copy of windows. A tribute to the absence of standardisation in the dirty computer industry.
  31. It's 90% done.
  32. It's a 'timing' problem. It is just not time for the software (or hardware) to work, yet.
  33. It's not a bug, it's an undocumented feature.
  34. Fix those f****** permissions!!!
  35. It's just a simple matter of programming.
  36. How did this ever work?
  37. We'll be done in two weeks.
  38. I don't have problems like that.
  39. The problem cannot be reproduced. Case closed.
  40. It only happens in the field. We cant reproduce it here / test for that.
  41. I could fix it if I had (pick at least one):
    1. An emulator
    2. A logic Analyzer
    3. A up to date prototype
    4. A decent hardware engineer
    5. Decent software tools
    6. Time and a half for overtime
    7. less paperwork
    8. less support tasks
    9. fewer meetings
  42. It conforms to the spec you signed off!
  43. We agree that the software performs to specification, but the specification does not make sense.
  44. I've just committed a change that might fix this. Just try it and see what happens. If nothing bad happens, then it is fixed
  45. I do object-oriented programming - if the customer objects, I do more programming.
  46. Real programmers don't document. If it was hard to write, it should be hard to read.
  47. A couple of Months? It's only Software!
  48. What do you mean putting 'runs without errors' in the specs?
  49. The bug's not that bad. At least it doesn't format your hard drive.
  50. This file is also distributed in Visual Basic for the "C"-ing impaired.
  51. Programming from a spec is like walking on water.... Its easier to do when it's frozen
  52. A Manager: "This fix can't possibly take two months, marketing has already promised this in one week".
  53. C++ is like teenage sex: Everybody is talking about it all the time, only few are really doing it.
  54. In C++ only friends can access your private parts
  55. We face new debugging challenges with the migration from C to C++ .
Personal tools