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
- a “Running Developer” spends little time thinking about alternative solutions
- he is very worried about deadlines and talks about nothing else
- he is sad for having to ditch quality and rush things, or maybe he developed cynicism and pretends that he doesn’t care
- fear dominates his activities
- he neglects testing to save time
Many of these symptoms relate more to the environment than the developer.
Autopsy
Many projects catch the “Running developer” disease, they are never diagnosed and die.
You can perform an autopsy to learn how to prevent the disease next time.
When you perform the Y-Incision to gain access to the organs of the deceased project, you find them scattered all over the place.
You wonder how it was possible that the project could still be alive when such a disaster was raging inside.
With the liver in the place of the heart, the spleen where there should be an ear, blood vessels instead of hair, the project was pretending to defeat the laws of physics to carry on.
Developers were busy trying to fix things. They tried everything: taking a foot and putting it in an ear, making a hole in the belly and have a hand pass through it, whatever.
They had to stop when they realised that nothing could save the patient.
The Patient Died From Perfect Health
Sometimes it’s even worse. The disease is even harder to identify.
The project seems to enjoy great health.
There is a wonderful, robust structure that doesn’t impede improvements.
The code works and it’s clean enough that it’s not a problem to add features or solve issues.
The project dies of sudden death.
What happened?
“Running Developers” never stop to ask questions. They strictly do what they are told. They implement what the client wants. They don’t try to understand what the client needs. It would be a waste of time and time is as scarce as unicorns.
The client gets an application they will never use because it doesn’t do what it needs to do.
The “Running developer” disease may be hard to diagnose
The disease is difficult to diagnose because its symptoms may not be recognized.
You may even mistake them for good things.
The “Running Developer” shows you a lot of working code very quickly because he skimps on structure, documentation and testing.
He works long hours. These symptoms may seem nice to have. You may misread them as a forerunner of success.
The disease will kill the project all the same.
How to cure the disease
If diagnosed in time, the disease may react well to a change in the working environment. Sometimes this is not possible and the patient will die anyway.
Other times you will find that the “Running Developer” has working habits that will ruin the project anyway even if you fix the working environment because habits are hard to die.
The Agile set of values and principles may be used to create a healthy working environment that doesn’t offer fertile ground for the disease to develop.
Photo by Arian Darvishi on Unsplash