Strategies for Successful Development

Process and technology for small teams building real software

Hug a Developer Today

Posted by S4SD (Seth Morris) on 2008/09/23

(I could argue the view that this video trivializes homelessness, but I’m not sure I believe it and this isn’t the blog for that. I will argue the view that this video trivializes the effects of bad project management.)

Watch the video, laugh, and share it with anyone you want to before reading on.

If you don’t want to watch the video (it has sound but does not need it), here are the texts of the signs the developers are holding:

  1. I am in pain
  2. We’re 4 months in to a 5 month schedule and I just received the final requirements yesterday. (And they’ve changed again!)
  3. I spend half my days in meetings about how to get more work done (instead of working)
  4. My boss read in a magazine that developers using "___" programming language are twice as productive. So he bought us a copy and cut our schedule in half.
  5. Every day my boss changes his mind about what we’re building.
  6. (Man) People keep asking me to fix their email, so I have no time to code
    (child sitting next to him) My daddy has no more time for me
  7. Some consultants told my boss they could build our next version in half the time, for half the money. He believed them but now they’ve spent all their budget, used all their time and are still only half finished. Now they’re gone and their code is a disaster. We have to fix it and finish what they started.
  8. (After the credits, in color, small child sitting on park bench) I just finished an intensive 6 week Visual Basic course

Sometimes I’m asked why I want to consult instead of taking a higher-paying W2 job with equity and a stronger career path or why I’m committed to project and process improvement in startups and small teams (which don’t have a budget for that kind of consulting). I’m never sure whether to tell them that it’s because I’ve seen the quality of life improvements for everyone on the team when a project is successful and the process is repeatable and predictable.

Engineering teams want to innovate on ideas, technology, and features, not process, and engineers (and artists, and writers, and managers, and marketers, and ….) want and deserve to have energy and time for their family, their personal and professional growth, and their own projects.

A programmer who sent this to me. I’ve known her for years and have been her team lead or manager at three companies. I know she’s experienced all or most of these and I know it has a real effect on her life (as it has on mine and many of my friends). These are the problems in the life of a programmer.

At the risk of killing the frog1, let’s break these down into some categories:

  • Failed Project management. These are the kinds of thing that developers live with every day but feel powerless over. Sadly, developers are sessile by nature; they will often put up with bad management, hating their job, feeling like they are failing, and feeling powerless over their work environment, for a very long time2. [items 2, 5, 7]
  • People in power who have a poor understanding of what development is3. Programming is invisible. QA is almost as invisible when it finds bugs and more invisible when it doesn’t. Programmers spend their time looking at source code, which is a static representation of an abstract process that will occur invisibly at a microscopic scale, or designs, which are an abstract representation of how poorly source code represents the problem domain. Unfortunately, even former developers fall into the trap of thinking that what isn’t tangible must be fungible. [3, 4]
  • The inherent pain in life of a developer. When you can do something, people expect you to do it. You want to do it. Since developers are able to do what they do anywhere and anytime, it can take over life easily; since developers are the most respected experts on an ubiquitous, increasingly-arcane, and increasingly-powerful technology, they are asked—and expected—to use that knowledge on behalf of their friends, family, and coworkers.
    We start out on this life wanting to play with things and to solve problems; we need training to know how not to do that when it costs us something (like time with our family) that isn’t in our faces while the problem is. [item 6; and arguably item 1]

These aren’t just one class of problem, but they are all real kinds of problems that burn out developers and destroy projects and sink companies. A good manager or lead can solve some of them and ameliorate others, but systemic change to address them all is very difficult. It to easy, and too common, to lump them5 together as "pointy haired bosses and bad planning," but we can’t solve them commingled that way.

That’s why I care about dev process at the leads and line managers level. It’s the fulcrum between failed project manager and poor understanding of development and engineers. It’s also one of the levels that can often remind a developer to step back and re-evaluate personal priorities.

So wait for HR to be looking the other way and go ask a developer if s/he wants a hug. (Don’t just hug them; many developers won’t like it… and some may sue.)

1) "Explaining a joke is like dissecting a frog: you understand it better, but the frog dies in the process." – Mark Twain (attributed, I don’t know if that’s accurate)

2) This is true of all people, really. It’s more visible in developers because of the shorter job cycle (longer times unhappy in shorter job lengths) and the how clear the effects of managers’ decisions are on the developers’ lives (ask a room full of developers how many Thanksgivings or Christmases they’ve been able to be home with their families; then ask then if it was because of things within their control).

3) I worked at a video game company for a while. Independent game developers doing the kind of license work we were (games based on TV shows, movies, etc.—I worked on the game Beethoven’s 2nd, based on the movies with Charles Grodin4) were at the mercy of the license holder, who were media companies and didn’t know what they wanted from a game. When I had been there a few weeks, a fellow developer told me that at the end each project they would give out the "flaming sphincter award" to whoever had been forced to redo the most work through no fault of their own (license holders deciding they wanted to add a bird to the game, that kind of thing).

I was warned that I would never receive this award and I should just let it go because "no amount of programmer pain is visible." My coworker was right; recognizing that helped me get through some tough projects and it helps mediate many difficult situations: no amount of developer pain is visible, even to other developers and certainly not to managers who aren’t around the engineers daily. What seems obvious from the engineering side is not misunderstood or ignored, it is invisible.

If you’re going to try and make that pain visible so management can recognize the problems and work on them, also ask what the developers can’t see and make the engineers aware of that. It’s basic mediation, but it’s especially hard when what each group wants is invisibly obvious to them and simply invisible to the other. Someone outside that chain of command is the best to help.

4) Admitting to having written this game is a big step for me. It is not the thing I’m most proud of. If you’d played it (and no one did), you’d know why. 🙂

5) And other classes, of course. If these two types of problems went away life would be much better, but even taken together they aren’t a silver bullet.

Listening to: Billy Idol – Rebel Yell – Rebel Yell



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: