A Difficult Software Developer so focused on getting the work done, that they completely forgo any notion of quality.

• Can mutate into: “The Soldier” Difficult Developer
• Dangerous when coupled with: “The Tyrant” Difficult Project Manager or “The Firehose” Difficult QA/Tester
• Likelihood of fixing: High
• Danger to project: Medium

Problem

The pressure on software developers is enormous. “The internet never sleeps” means that often neither do software developers. In order to try and regain a semblance of work/life balance, The Bull in the China Shop developer just wants to complete their list of tasks as quickly as possible and get home to their family.

The Bull in the China Shop is created by project pressures. No matter how good the developer, if project pressures increase enough, they will inevitably stop testing their own work, and instead rely on QA (see “The Blamer” QA) as their exclusive means of finding bugs. Furthermore, in the name of expediency, they will forgo practices such as peer code reviews; automated testing; and refactoring; leaving the code in a state of disrepair. This poorly designed software then causes new bugs, and the codebase rapidly deteriorates into a geyser of bugs that can never be plugged.

The Bull in the China Shop is living in a constant state of stress, inflicted upon them by those in charge. They are victims of a poorly planned and run project, yet they are seen as the problem. The phrase “Burn-out and replace” is used in reference to Bull’s in the China Shop, as the constant stress will eventually break them, and they will either leave or be fired due to their perceived incompetence.

Solution

As they are not the problem, the problem must be rectified by the organization taking the following steps:

1. Put a hard break on the project to create some breathing room. This is normally done by dramatically reducing scope or pushing out the deadline considerably.
2. In the calm period this creates, facilitate a candid “lesson’s learned” where The Bull(s) in the China Shop have the opportunity to air their grievances.
3. Do a root cause analysis of the bugs, and fix the root causes. Do not rush this, and make sure they are all addressed before proceeding.
4. Address any cases of burnout among the developers by forcing the developers to take off-the-books time off. Organizations rarely do this, but it is highly effective.
5. When the team regroups, assess the project holistically to set new scope and delivery dates.

While these steps offer a clear path to fixing the problem, they are almost never taken as management is the cause of the problem, yet management must be the source of the solution. However, provided management recognizes their role in creating Bulls in the China Shop, in a few weeks the damage can be repaired and the project put back on course.