1) My code is better that yours. Writing code is very much like writing a song or painting a picture. Artists and song-writers have different styles of painting or song writing. Writing code is similar, different software engineers have different coding styles. So, unless your code is really badly written, my code is no better than yours, it is simply different to yours. If my code works and does not require any enhancements, leave it alone, no matter how different to yours it is.
2) It works on my machine…well, if it works on your machine and not mine, then clearly it is not a robust application, or your installation procedure does not work very well. Remember that you wrote it on your machine, so of course it works on your machine. Now get it to work everywhere else.
3) I’ll comment the code at the end. The end of any development cycle is always chaotic, that is a simple fact of software engineering. So, if you have not got time to comment your code while you are writing it, how are you going to have the time at the end? Besides, if it is a large project with a long development time, are you going to remember what some of the earlier written (uncommented) code does!
4) I’ll add the error handing at the end. Error-handling is part of the basic design of a system, not something you slap on at the end when you have time.
5) The programme is complete – but I just need to quickly finish off…..This is a very common one. The development is not complete until you have finished writing all of the code. If you have a single line of code to write, it is not complete, and not ready for testing.
6) It is a small bug – it will only take 5 minutes to fix. By the time you have load the development environment, identified the bug, fixed, tested and rolled out the change to production, it will be much longer that 5 minutes. There is no such thing as a 5 minute to fix bug.
7) I only have to change one line of code to fix the bug. To the customer, it does not matter weather it is one line of code, or one hundred lines of code. All the customer cares about is that the application is not working. Fix it!
8) It’s not my problem. If your application is not working – it is your problem. It does not matter if RightFax is down and you cannot print faxes, or you cannot connect to the FTP server. The fact is that if your application is not doing what it should be doing, you had better find out what the cause is, and resolve it. While different people may have ownership of different portions of a software system, you are ALL responsible to ensure that everything is working.
9) The application works fine with my test data. Yes it might, work with the test data, but the live system does not run on test data. It runs on live data. Best you get your application to work with live data.
10) It’s a user error. If the user is clever (or stupid) enough to break your application, it is not robust enough. You need to anticipate all user inputs, and cater for them. If at a later stage you find another user error, modify your code and test cases to check for it.
And a bonus lie…
11) Of course I test my own code. Do you? Really? Promise? Ok, then let me try to break your application.