(^_^)

Reproduced from the Learning Product Management board on Quora.

One warning sign I’ve developed a sense to watch for is when a developer reports that something is or was “hell” to implement. This often translates to an incomplete understanding of the problem, the solution, or the technology needed to implement the solution. Having an incomplete understanding is natural when solving new problems or learning about new areas. However, an incomplete understanding becomes dangerous when coupled with a lack of desire or inability to gain understanding.

Without adequate understanding, programmers may engage in guess-and-check programming. They stumble closer to a “working” solution by guessing at changes that might fix an issue encountered, checking after each to see if it does. This may be appropriate in some very limited situations. More often, however, bad things will happen when programmers make lots of changes to fix issues without understanding why it appears to work. Without taking the time to understand, they will miss things or cause unintended consequences, i.e. side-effects. This creates a form of technical debt which causes problems for all involved down the road.

There are many reasons why someone may not get an adequate understanding. Perhaps they feel it is not important, or underestimate the complexity. Perhaps they are under a tight, externally imposed deadline and lack the confidence or perceived authority to challenge the deadline given the situation. Or, perhaps they simply do not realize that their understanding is inadequate due to inexperience or stubbornness. It takes a certain level of maturity to realize that you’re in over your head, and need to take a step back, when you’re already on the battlefield.

One thing that you and fellow team members can do to help is to watch for the warning signs and react to it. It’s in all of your best interest to do this. As a product manager, you’ll pay the price if you don’t. Some of the consequences include having to incur the cost of fixing resulting bugs, pissing off customers, and perhaps even having to completely redo a feature. I’ve faced these consequences many times, and thus have become sensitized to the warning signs. The one that I pointed out at the beginning of this post, when something is referred to as “hell,” is a common one on my team.

If you recognize the warning signs, you can take steps to help the impacted developer or team before it becomes a serious issue. The steps to take depend largely on the situation. Here are a few you might consider.

First, you can ask them about it. Just having someone serve as an outside observer, in a constructive way, can help give someone the nudge needed to get unstuck from the muck. For some teams this can be done directly. On other less healthy teams the direct approach may be perceived as threatening. In this case the same effect can usually be achieved indirectly, through a team lead or manager.

Second, if you know of someone else inside or outside the organization with a better understanding of that area, you can attempt to hook the developer up to that resource. Alternatively you may be able to do a bit of research and find good materials on the Internet.

Third, you can be supportive. Offering to talk candidly about a deadline, scope, or importance of an issue indicates to developers that it’s OK to bring up issues that may cause delays, and that properly executing a feature is usually more important than sticking to a deadline. Of course this option must be exercised with caution—you don’t want to lose any perceived urgency that you have painstakingly built up, but yet you want to foster a healthy and supportive environment. Striking a balance is difficult but important.

Finally, you can work with the team on an alternative. Sometimes something that is causing a lot of frustration or will take a lot of time to understand adequately may not be worthwhile. There may be an alternative approach or solution that is more desirable, given the level of effort involved. If, on the other hand, it is actually very important, you can make sure that the developer understands just how important it is an why. This knowledge helps arm them against the doubts which will rise in their mind against their own judgement, and justify the level of care necessary in the work. The team will look to you to help make that determination.

These are just some examples. Inevitably you’ll find many intelligent ways to handle this situation. However, you can’t react to the warning signs unless you know how and what to look for. My friendly advice to you is to pay attention to your team and look out for warning signs such as the “hell” heuristic, and to then take steps necessary to ensure your team is not sacrificing understanding and thoroughness for expediency. Otherwise you’ll likely regret it later.

Posted via email from Learning Product Management | Comment »