Saturday, May 16, 2009

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.

3 comments:

Chris said...

Another great article but I have a question: Many frameworks and libraries out there seem to be satisfied that the javadoc, gdoc, rdoc, whatever seems to be all the documentation that a particular library needs where I think that understanding why is just as useful as knowing how to do something is just as important. With Agile software development practices, is it considered a virtue by some/many to provide as little help/documentation as possible? Is operational support and maintainability outside the scope of agile software development? (You can guess that I'm probably not to keen on what Agile really is)

@DustinMarx said...

Chris,

I'm no expert on agile development and, in fact, am similarly frustrated with the conflicting and contradictory statements about agile development from self-professed agilists. I tend to give more credibility to those who actually came up with the Agile Manifesto, such as Martin Fowler and Robert C Martin.

With working software over comprehensive documentation being one of the four main principles of the Agile Manifesto, there is obviously some backlash in the agile community against too much or needless documentation. However, I think some misguided individuals have taken that to mean no documentation at all or too little documentation. It seems like many "thought leaders" in the agile community are acknowledging that some documentation is needed and the emphasis is instead of reducing redundancy in documentation and not allowing generation of documentation to negatively impact development of software. I personally think that operational support and maintainability should NOT be outside of the scope of agile, but that is just my opinion.

The concept of documentation in agile development does seem to be a little "squishy" and hard to define. I personally think one should not be too bound to any methodology, including agile, and should do the right thing for the situation and let one's own experience guide decisions.

There does seem to be some consensus building in the agile community around acknowledgment of need for a certain level of documentation beyond the code itself. Relevant references include:

Examining the Agile Manifesto succinctly treats the working software over comprehensive documentation and explains that documentation is needed to explain certain things, including the "why" you mentioned.

The New MethodologyAgile Development: Don't Forget the DocumentationAgile/Lean Documentation: Strategies for Agile Software Documentation

Chris said...

Dustin, thanks a lot for the reply. You know, I'm not a software developer but I'm someone interested in learning ruby, groovy, etc. in order to become better at my systems administration job but then I find something like this:

Ruby Net HTTP Options Method Documentation And this is from the documentation from the standard library? I think it would be tough as far as language adoption goes when users new to a language are told that all they need to know is in the rdoc and this is what one winds up finding when going to the docs.

Java is a bit better for the most part but there are still lots of examples.

Well, thanks for letting me rant on your blog!