Is your software project safe from the disease of running developers?

One of the reasons for which 70% of software projects fail is that they catch a disease called "Running Developer" and die from it.

A project suffering from this disease and not diagnosed in time may survive for many months or even years. Its breathing becomes eventually laboured until it stops.

Is it possible to diagnose this disease?

Happily, "Running Developer" is a disease you can diagnose. Maybe with the help of an expert.

Or maybe you misunderstand the symptoms and the patient dies anyway.

Symptoms of "Running Developer"

You can look for symptoms in the code the "Running Developer" produces:

  • there is no structure
  • there is no documentation
  • in case the software stops working it tells nothing about what happened
  • the code adheres to no stylistic conventions
  • there are no automated tests

You can observe the developer working habits.

  • she works long hours
  • she does nothing to take care of her well-being (she moans: "Who am I to deserve any care? I'm bad, I'm behind schedule.")

You just throw a glance at the developer.

  • he looks tired
  • his aspect is unkempt
  • he looks worried
  • he speaks very quickly and is convinced that it makes him more productive
  • no smile

You enquire about deadlines.

  • there is strong pressure to meet deadlines
  • managers set deadlines without consulting developers
  • deadlines are unnecessary and managers set them only to "improve productivity" (They say: "If we don't set the most deadly deadlines, nothing will get done.")

You investigate team dynamics.

  • the developer doesn't get help when they need it because everyone is too busy to help
  • she insists to say that a problem can't be solved when it actually can
  • she never asks questions to understand what the client's needs are, she has no time for this
  • she is forced to participate to meetings whose purpose and usefulness she doesn't understand or that don't have any
  • team members and managers don't trust the developer

Management style

  • the developer is micromanaged
  • she is forced to report on the status of her work very often
  • she is not trusted
  • managers pressure her to perform
  • managers force her to wear a device that tracks every her movement to "improve productivity"
  • she is a bit older than average (20 years old instead of the mandatory 12). HR hired her because of her experience, but she doesn't bang on the keyboard at the required minimum speed of 3,000 words per minute, wants to think before plunging into work, wants to do things right, wants to communicate because Agile is all about communication, dares to say that she works less than 996 to keep herself productive, should be shot.

Motivation matters

  • the developer doesn't really like writing code
  • he is not motivated because he would like to write quality code, but he has no time for this
  • he focuses on money, recognition, career ladder, everything except building first-class applications. No time for that.
  • he thinks that his work is meaningless

The working environment influences

  • the developer has to work in a noisy environment where he is frequently distracted. Everyone around him believes that to make him productive the only thing to do is to pressure him, the environment doesn't matter.

Thinking process


(full article: Is your software project safe from the disease of running developers?)