Goals, Not Tasks

From my recent posting history, you might tell I'm on a real kick about how work is split up on software projects. Well, that kick continues because I just read a great post from Charles Miller called Decluttered Software Development. I particularly identified with the section in which he discusses assigning goals to software developers rather than tasks.

One of my longstanding pet peeves in the software industry is the way in which some managers treat developers as if they're highly paid instruction followers, like computers themselves, instead of rather intelligent human beings who can comprehend high level business objectives.

Here's Charles:

If somebody takes ownership of a complete goal, they feel responsible for delivering it as best they can, even the bits they discover on the way that they didn’t know about when they took responsibility for it.

When you split a goal into tasks, you are redefining “achieve this goal” as “complete this set of tasks”. Developers own their individual tasks, nobody owns the gaps between them, and anything that shows up after that initial split inevitably floats all the way back up into the project-wide planning process for expensive renegotiation and rescheduling.

Often these things that fall between the gaps won’t be noticed until long after the feature is “delivered”, because nobody at the developer level is thinking about the problem as a whole any more, just about the component parts it was split into during some meeting.

There's a whole class of bugs that comes down to the developer followed very specific instructions without understanding the goal. And a well-meaning manager will take that to mean I wasn't specific enough in my instructions. No! Computers need instructions. Humans need understanding.

I hope I'm not beating this dead horse until the end of my career, but I must again point out that user stories are essential to organizing the work on a software project. If the developers are not focusing on the users' goals, then they cannot make good software. Developers don't need better instructions. Developers don't need more detailed tasks. Developers need understanding of the users' goals.