One of the most sinking feelings one can feel in software development occurs when a client or management overreacts to some crisis or mistake with onerous new requirements, procedures, and processes. In this blog post, I look at why those in authority sometimes do overreact, describe why overreaction can be dangerous and costly, and outline some ideas regarding how to reduce or prevent overreaction.
Why Do People Overreact in Software Management?
There are several explanations for why people overreact in management of software projects. Most of these are applicable to general overreaction in any area, but do apply specifically to software development.
Emotional
By definition, overreaction is associated with an emotional response that is inappropriate to the circumstances. Emotion can cloud over or completely obscure logic. Many poor decisions in life have been made in the heat of the moment when emotions run high and logic runs low. Emotions are usually high as a direct result of the incident being overreacted to. Often these incidents are most glaring when we can least afford them and stress levels are already high.
Helplessness / At Least Do Something
Another reason one might overreact is out of fear of not knowing how to resolve the situation in a reasonable fashion. If there is a problem with no clear solution, it may feel better temporarily to at least do something even if that "something" is not rationale or even a good idea. Sometimes the best thing to do is to do nothing, at least at first. Calmer heads are more likely to come up with more useful ideas for dealing with a particular issue.
Punishment
Overreaction may be directed at one individual, a team, or even the entire staff as a form of punishment. This is a little different than the previously covered reasons because it is more calculated and deliberate. However, that does not mean emotion is not involved; the desire to punish is often emotionally driven.
Send a Signal
Another calculated reason a person in authority might overreact is that he or she wishes to send a signal to other developers that certain (mis)behaviors are not tolerated. As with the punishment motivation, the person overreacting may be doing so intentionally to send a "stronger signal."
Lack of Understanding of True Cost of Overreaction
In some cases, a person in authority might feel their newly imposed procedure or process is perfectly reasonable because he or she does not understand the true cost and true negative consequences of it. This typically happens when a person with little or no hands-on software development experience attempts to decide on extreme measures related directly to some stage of producing software without consulting people in the know.
How Costly is Overreaction?
The total cost of overreaction is nearly impossible to quantify because it is so highly dependent on the situation and on the degree of overreaction. However, there are many different costs to overreacting and some of them are listed here. To illustrate many of these points, I will be using a simple example of an incident such as breaking the build.
Direct Cost can Exceed Original Incident Cost
Suppose that the build is broken occasionally because of developers in a rush. It is not a frequent event, but does happen from time to time. If the estimated lost developer time is, hypothetical speaking still, about 5 person-hours per week, it makes little sense to impose new procedures and policies that prevent that build breakage that require 50 developers to spend an extra 30 minutes per day checking out their code before merging. That's because 50 developers multipled by 0.5 hours per week means 25 person hours are spent to avoid a 10 person hour problem. That is an overreaction. The cure is worse than the disease.
There are cases where the extra time to avoid the problem may be justifiable. I am especially thinking of situations where one deems the quality benefits of the additional steps to be an advantage. However, if the new procedure is instituted solely to deal with the hours wasted on a broken build, it is nonsensical and counterproductive to institute additional procedures that will take more time than the thing being avoided.
For me personally, it is often better to have one longer work stoppage now and then as opposed to transitioning on a daily basis between the work I really need to accomplish and the mind-numbing steps added to avoid "incidents."
Unintended Consequences
Besides the direct costs of any new initiative instituted as part of an overreaction, there will almost certainly be unintended (and often negative) consequences. I have written before about the dangers of unintended consequences. These are especially challenging to quantify, but always seem to apply. A newly enacted procedure might be intended to reduce a certain undesirable event, but in the process leads to one or more different undesirable events. This can be especially true if the concept sprung from overreaction leads to cloaking bad incidents rather than actually preventing them.
Collateral Damage
One of the reasons that overreaction can be so disheartening to software developers is that we often know that the innocent are going to be treated in the same way as the guilty. Even worse, highly skilled and very experienced developers can sometimes be forced to endure the same restrictions applied to newer and less experienced developers after an incident occurs. In many aspects of like it is a laudable ideal to treat everyone the same, but it is a mistake in software development to treat the craftsman the same as the apprentice. Even worse, it is really despicable to treat the craftsman the same as the incompetent. Processes, procedures, plans, and initiatives spawned from overreaction often lump everyone together and deal with the least common denominator. There are many costs associated with this: lower productivity from the most productive developers, dissatisfaction in the people that are most difficult to replace, and lack of attention on the people who really need it.
How do We Prevent / Reduce Overreaction?
Count to Ten
Often the best way to avoid overreaction is to take the emotion out of it. If you're in the authority position or can influence the person with authority, try to wait at least a day (or preferably over a weekend) to allow emotions to cool and to reconsider the true cost of the incident you are tempted to overreact to.
Understand the Direct Costs of Your Reaction
Some of the worst consequences of overreaction I have seen are those that occur because the person making the decisions did not really understand the costs or consequences of their decisions. Before a decision is made like, "Before doing procedure A, one must always do procedure B," the person forcing that procedure on others should do them in a realistic environment to see how painful and costly they are and to truly determine there effectiveness.
Consider Unintended Consequences
One of the hallmark characteristics of many decisions made in haste and with emotion is that only one consequence is being considered. The decision usually does directly deal with that considered consequence, but it is important to consider the other consequences. As an extreme example, not allowing developers to write code will eliminate the addition of new bugs into the system. However, there are other consequences of this action such as no new code being written or maintained.
Apply Tweaks Rather than Seismic Shifts
One of the problems with overreaction is that it often leads to decisions that are not appropriate in terms of degree of seriousness of the original incident. It can often be better to reduce the first idea one has for dealing with a crisis to a smaller, less significant change and measuring if that is sufficient to meet the problem. Often, if cooler heads prevail, this is what happens anyway.
Acknowledge that Not Everyone is Equal in Experience and Skill
If developers have different grade levels or other indicators of their experience, then why not tailor processes differently for each grade level. If feasible, it would be even better to tailor to each individual. Much of the more successful open source community uses meritocracy in a similar fashion.
Contingency Plans
A big part of overreaction is often due to fear, shock, and a sense of hopelessness. This can be mitigated by considering some of the common things that can happen in software (hardware failures, defects, delays, difficult to maintain code, etc.) and have plans in place beforehand regarding how to handle them. This may help identify small steps that can be taken to reduce the likelihood of the problems in the first place and can provide calm and logic when the incidents do occur. Being proactive allows one to be less reactive.
Admit Mistakes
If a bad plan is put into the place as part of overreaction, the worst thing that can be done is to leave it in place to save face. It is better to admit that a response was overly reactive and either temper it or remove it altogether. This can be difficult to do even though it is the correct thing to do.
Conclusion
It can be very easy to fall into the trap of committing an overreaction to a significant event or incident. Unfortunately, this often exacerbates the problem and exasperates the development team. In this blog posting, I've looked at why we are prone to overreaction, some of the costs of overreaction, and some techniques to reduce the frequency and severity of overreaction.
Please feel free to add in the comments any reasons, costs, or remedies you have observed related to overreaction in software development.
No comments:
Post a Comment