Why Development Projects Go Wrong #2 – My Developers Just Don't Get It

Communication between software developers, project managers and users is important to any software project. But it's not easy. And when things go wrong, it's common for managers and users to get frustrated with software developers for not having what they regard as common sense.

Developers, by the way, will often say the same thing about managers and users.

This happens often enough for me to think it's a common thread in development projects and not actually because one group or other actually lacks common sense.

There's a big cultural divide between developers and most other professions. Developers are forced to think in a particular way because they spend 8 hours a day explaining to a computer, how to do things.

People in other professions may spend 8 hours a day sitting at a computer, but they are not interacting with it in the same way that developers are. Usually they are communicating with other human beings via the computer. Or they are creating artefacts using the computer that another human being will see. This is not quite the same as coding.

Have You Actually Made it Clear What You Want?

When people get frustrated with developers, my first port of call is usually to listen, to sympathise and to try and calm the person down. But once that's done, I try to tease out of them some details about what they have actually said regarding what they want.

Have they described in a clear, specific and objectively measurable way, exactly what they want?

Usually, when things have been going wrong, I find that they haven't. Usually, before long, they say something like:

that's obvious, surely!?

I sympathise, I really do. But, no. It clearly isn't obvious. Not to developers. And it's pointless hoping that that will change.

There are things you can do to mitigate this problem though:

• Build a process which asks the right questions and teases out important details. For example, write user stories, draw wireframes and use a checklist of common questions.
• Give developers context, show them round the user's workplace. Explain how it all works. Developer's have to learn new technologies every 3 years, they're very good at picking things up.
• Ask the developers to demo their work early, and at regular intervals. Get them to explain the process back to you. Then, build time into the plan for re-work.

The vast majority of the developers I've worked with in my career have been hard working, motivated and intelligent individuals who wanted to do the right thing. But sometimes even the best of them would utterly fail to 'get' what it is they are building and why doing it one way is right and the other is wrong. Fortunately though, this problem is avoidable with hard work and careful management.