Not All Help is Helpful

We all are exposed to and often use euphemisms to reference something unpleasant with a more pleasant word or phrase. Popular euphemisms (at least to the user of the euphemism, but often not to the recipient) include workforce realignment, pursuing other opportunities, and headcount restructuring. I have noted that the word "help" is also often used as an euphemism.

"Help" is one of those words that can be what it actually portends to be or can be an euphemism. In this way, it is like "agile development" and many other trendy computer science terms. There are disciplined practitioners who do try to practice agile (think the original creators of the Agile Manifesto), but there are also less scrupulous (or less informed) developers who have corrupted the term "agile" to be a euphemism for no documentation, no design, or lack of anything else they don't want to do. "Help" suffers similar double meanings. On one hand, someone who offers help can really mean it and can really provide it. On the other hand, "help" sometimes is intentionally or unintentionally more of an euphemism for something not so positive.


Alternative Meanings / Implications of "Help"

Offered "help" can sometimes turn out to be the exact opposite of that. In other words, the attempted "help" can actually hinder or slow progress. The following is a brief list of actions that are often thought of as "help," but often are exactly the opposite. I am sure that this is only a subset of the various actions software developers have encountered under the guise of "help" that are really not that helpful.

Micromanaging

It is an ironic twist that well-intentioned folks can actually impede the progress of a project while trying to help it because they too frequently request status, because they override reasonable decisions because they think their approach is quicker, or because they watch over the person's shoulder to make sure they don't make the slightest mistake. All of these can be symptomatic of micromanagement and tend to hinder rather than help. I have blogged before on how the very act of measuring progress can hinder the very progress being measured.

Throwing More 'Resources' At It

Brook's Law is Fred Brooks's "law" from the oft-quoted The Mythical Man-Month in which he states that adding people to a late project simply makes the project later. There are many reasons for this including the delay foisted on the current team to teach the new team members what the existing team members already knew and the added overhead that comes from additional communication needs and miscommunication mistakes. Although The Mythical Man-Month is one of the most frequently quoted and read books in the genre of software development management, it still seems the first thing we want to do with a late project is throw more people at it, even if that doesn't really help.

(Over)Reactionary Tactics

"Help" can be a euphemism for overreaction as well. A client, manager, or colleague may insist on a new and tighter process to "help" avoid mistakes. The action may indeed reduce the likelihood of whatever mistake it was aimed at from occurring, but sometimes does this at far greater cost than the cost of the incident being avoided. For example, if an extra step in a process avoids a type of mistake that happens about once a week and causes 2 hours of downtime for ten developers, but the extra step costs the ten developers one hour per day to implement, the "cure" is worse than the "disease." Often in these cases, a less reactionary and slight change in process is all that is needed.


Making 'Help' Actually Help

There are tactics one can use to increase the odds of offered and provided "help" actually being helpful. Some of them are listed and described here.

Partition Work for the 'Additional Resources'

When provided with additional "help" in the way of new personnel, this can be more helpful if the new personnel work on things with the least need of mentoring and tutoring from existing personnel and if they work on things in which they are least likely to "step on others toes." They might be able to help with things that need to get done but aren't high on the current developers' lists. Depending on the environment, these could include things such as integration testing, user documentation, and so forth.

Tell Others How They Can Help

Perhaps the best way to ensure that intended "help" is actually helpful is to spend a little time figuring out what would actually be helpful and making those observations clear to those providing the help. Clients, supervisors, and colleagues want to succeed and really believe they are helping even when they are not. These well-intended individuals can actually be helpful if they really understand how they can help. The best way to ensure they understand how to be truly helpful is to tell them how they can be helpful. Most of us have little things we want to fix in our code or we have questions or concerns about something we'll be getting to later. We can express these concerns and questions and get additional people involved in resolving these potential issues in advance of actually having to handle them.

Explaining to those in charge what reasonable measures would best resolve problems is especially effective because it can reduce the likelihood of overreaction.

Avoiding Unnecessary 'Help' Altogether

One of the best ways to avoid getting unnecessary "help" or something even worse under the euphemism of "help" is to make sure that those who might be likely to provide such "help" understand that no help is needed. I have never believed that it is a good idea to ignore problems or pretend they are not there. So how does one make sure that unnecessary "help" is not provided even when one has to report bad news? The best way to avoid unnecessary help in such cases is to provide the plan one has already come up with to get out of any bad situations and/or to avoid any particularly costly mistake from happening again. There will be less perceived need to force "help" onto a team that has already observed how to get itself out of a mess and/or avoid a similar mess.


Conclusion

As I stated above, all stakeholders on a given software development project generally want it to succeed and will do what they think is appropriate to increase the chances of success. Unfortunately and both intentionally and unintentionally, this can sometimes lead to "help" that turns out to actually be anything but help. Indeed, it can be easy to start to see "help" as a euphemism for something less desirable such as micromanagement, increased scrutiny, and other actions that actually exacerbate the problem rather than remedying it. We can reduce or minimize the negative effects of well-intentioned but negative "help" by providing our own proposals for how to best get out of a particular bad situation and letting others know what they can do to be truly helpful.