Monthly Archives: January 2011

How to Recognize Bad Software Developers

There is a lot of bad software out there and that upsets me. Software is going to be everywhere. It’s already in your TV, washing machine, microwave oven, car, mobile phone, and hundreds of other places. Most of it is pretty low quality.

I want to live in a world where software — or anything that uses software — is dependable, safe, and a lot less frustrating to use than it is today. But writing software is hard and a lot of developers are way out of their league.

Here is a checklist on how to recognize bad developers. You do not want to hire people who exhibit these symptoms!

Bad developers…

…make overly optimistic promises. Software development is hard and it almost always takes longer than expected. Of course you want to release as soon as possible but an unrealistic plan won’t get the project done any sooner.

…claim to fully understand your specifications without asking questions. Trust me, there are errors and omissions and unanswered questions in your specs. You don’t want the developer to make assumptions, you want him to ask for clarifications.

…start programming right away without understanding the actual problem to be solved. The developer is not an expert in your field, so it will take him a while to learn about it. Expect to explain stuff. A good developer will try to understand what he is going to build before he starts building it.

…write code quickly (but badly!) to try and impress you. Unfortunately, the bad developer can only deliver quickly by skipping corners. Those skipped corners will come back to haunt you near the end of the project, causing delays that undo any gains from a quick start.

…will do exactly what you say, without any critical thinking on their part. So you have to take them by the hand and micro manage them the whole time.

…keep adding features that you did not ask for because the developer thinks they are cool.

…use open source code without respecting the license, putting you at risk legally. Code-reuse is a good development practice but there are limits to how far you can take it.

…don’t deliver on time because weird bugs keep popping up. These weird bugs are the result of the cowboy coding at the beginning of the project. It’s impossible to fix these bugs properly because by now the code is a mess and the bugs are entangled deep within it.

…write code that is totally unmaintainable, which makes building the next version of your app an even worse ordeal.

…may not actually be able to program what you asked for and will be forced to abandon the project halfway through, after you’ve spent countless hours and a large chunk of money on it. The next developer you hire will probably have to start all over.

These days it is easy to get into programming. Anyone with half a brain and a text editor can put together a website with some HTML and PHP. But that does not mean that person truly understands what he is doing. In my experience, the craft of software development takes at least 10 years to learn and much longer to master.

If you want your project to be a success, take the time to find and hire someone who has put in the effort to learn what it takes to write good software. They may charge more but in the end you’ll be a lot happier for it.