Skip to navigation

malevolent design weblog

This blog is now defunct, but you can find more stuff over at my personal site

Software Development Myths

Most people don’t really understand what programmers/developers/software engineers do, and I regularly encounter these myths, even amongst those working in software companies:

Myth 1: Creating software involves magically-/overly-complicated technical stuff

Programming’s ultimately nothing more than telling a computer precisely what to do using simple instructions. The complexity of the task dictates the complexity of the system, there’s no unnecessary intricacy introduced by the act of programming itself, in fact it’s mostly about trying to understand and simplify things through sensible architecture and abstraction.

Good programmers are able to demystify what they do and bring order and clarity to chaotic projects. Bad managers often seem to think good programmers are overly fussy or pedantic, when in fact they’re merely trying to consider potentially troublesome details rather than glossing over them.

Myth 2: Programming can somehow be dumbed-down so that skilled programmers aren’t needed

Every now and then someone hypes a development tool that will supposedly take the programming out of programming, allowing anyone to produce amazing applications and saving cash by cutting out those expensive diva coders. Funny how those coders are still around and always busy with work, eh?

The right tools can help tackle common or repetitive elements, but every project’s different and there’s no way around the analytical skills required. Someone still has to carefully devise and describe the operation of the system; programming is a deeply creative activity.

One nasty side-effect of this myth is the creation of programming languages with English-like syntax. As John Gruber has just pointed out, this introduces an unhelpful vagueness without actually simplifying the logic in any way.

Myth 3: A project specification can precisely describe every aspect so that skilled programmers aren’t needed

Lots of companies love the recent outsourcing trend. No more pricey programmers making the office look untidy and asking awkward questions! Not only can you pay a pittance, they’re also so far away you don’t have to awkwardly look them in the eye while handing over the cheque.

OK, so it’s not always like that, and there are great coders all over the world who are now part of a global open marketplace, but some companies are adopting a crude and patronising approach to their outsourcing. The idea is that you only need one senior in-house programmer to draw up a specification, then you can hire just about anybody anywhere at any price to do the donkey work and the project can’t go wrong.

A good specification helps safeguard the overall architecture, but it can’t (and shouldn’t) cover everything. To quote a consultant I once worked with:

The only complete description of the system is the system itself.

There’s no point trying to describe every last detail; even if you succeed then all you’ve done is code the entire project in a format you can’t directly use.

Even though coding isn’t important, bad programmers will always find ways to screw up, no matter how thorough the spec., and good programmers won’t produce great work if they’re treated like chimps for hire rather than being fully involved in the process.

Want to know the secret of successful software projects? Hire a small team of highly talented people (including the best technical manager you can find) and let them get on with it. Of course, the tricky bit is finding the talented people…


Well put.

— Greg, 28th Sep, 11:36pm

Comments are now closed for this entry.