This post is not another list of security mistakes in web application development – not my cup of tea. No, this is a list of the top five programmer errors. That is, errors made by software development professionals performing their craft.
No. 1 – Writing Too Much Code
“If I have seen further it is only by standing on the shoulders of giants” – Sir Isaac Newton.
I recently came across this post by Chris Williams asking for help in finding a bug that resulted in “serious error in the debugger”. There were actually several bugs in the code, some worse than others. One of the proposed solutions also produced a new bug, though less serious. The bottom line – a whole bunch of code could be replaced with a single library call. Now, it’s nice that today’s frameworks have lots of high level method calls preventing you from writing too much code. But what is really nice is that the less code you write, the less bugs you insert into your projects. Failure to take advantage of this gift comes in as the number one mistake programmer’s make.
Don’t write so much code!
No. 2 – Ignoring the Problem Domain
How many times have you seen an “ini” file reader that simply trades one storage mechanism (an INI file on disk) for another (a dictionary of key/value pairs). What’s the point? While this may be appropriate as a middle-tier step, there is a problem domain in there somewhere, right? A “To Do” application with categories can store its information in a ini file (or any other back-end store), but when I read it from storage, I want the result to be a collection of categories, each with collections of tasks hanging off of them. Not some dictionary for me to parse later (typically throughout the application several times over).
Move closer to the problem domain. Whatever your application is. If you are developing a generic solution/library, use a layered approach with problem-domain specific objects built on top of generic, low-level objects. Solving problems with data structures (consider the System.Data.DataSet object in .Net) shows up often enough to make this the number two mistake that programmers make.
Don’t ignore the problem domain.
No. 3 – Inappropriate Level of Rigor
Everyone likes one size fits all. Too bad one size never really fits all. Not enough design, too much design. Not enough specification, too much specification. Not enough test, too much test. Not enough extensibility, too much extensibility. Not enough documentation, too much documentation. Zealots in some of these areas will let you know that you can never have enough ___. You can always have too much X. More often, there’s too little: Design, specification. Sometimes, there is to much: extensibility. Sometimes both extremes are common: Test. [Nobody knows what to say about documentation – we like to say ‘never enough’ while refusing to read what little is there]. I don’t know what the correct level of rigor for your project is, but if you don’t think about it – and just do whatever you did before – you are making the number three mistake on my list.
Consider the level of rigor for each project you undertake.
No. 4 – Programming by Accident
“Works for me” – anonymous
When you don’t know why something works – find out. There is a world of difference between “working code” and “good code”. Never be satisfied with “getting lucky”. Your test case works, but you don’t know why. Not a good place to be. Understand what you are doing, understand why it works, understand when it works, and more importantly understand when it does not work. If you don’t know something – you have work to do. If you take a look at the post mentioned at the start of this document, the author states that in one case “Button1 read in File1 via a StreamReader and works perfectly”. No, it worked in that case by accident. If it works for you, but you don’t know why, then you are making the number four programmer mistake – programming by accident.
Don’t program by accident.
No. 5 – Tools are Not the Answer
Tools are great, but they are never the answer. Tools improve productivity. Tools used correctly improve quality, but they do not solve problems. Tools are good for problems that have already been solved, not ones that need programmers to solve them. Your tools will change, and there will always been another tool. The number five mistake programmers make – suggesting a new tool for an old problem.