Stop being so agreeable!

I confess, this is heavily influenced by the eXtreme Programming folks, but I see it recur again and again: we tech folks have historically been far too quick to say “sure, we can do that”. Even worse, I’ve done it myself on far too many occasions.

Yes, we want to be “team players”. No, we don’t like conflict. Yes, often the changes we’re asked to make are technically “interesting” and we like challenges. None of that matters at all. We fail in our duties when we don’t add the important bit to “we can do that”: “It’ll take a month of my time, and features X, Y, and Z won’t be in the next release.  Is this feature worth it?”.  I’ve found it astonishing how often the answer is “never mind”.  And the new feature goes on the “future release” list. And then it’s forgotten as other higher-value features take precedence.

And even worse is the post-mortem. Where the beleaguered techie says to the stake-holder, “Features X, Y, and Z aren’t in the product because we put in feature H that you asked for. It turned out to take longer than we thought even though it sounded easy”. And the stake-holder replies, “I was just thinking out loud, it wasn’t that important.” Followed by the soul-crushing comment, “And I don’t like how it works anyway”.

Important note: I am in no way bashing the stakeholders. Well, not much. I’m bashing techies (I think I’m entitled, I’ve been one for 30 years). Stakeholders simply cannot make rational resource allocation decisions without knowing the costs. I’ll bash management a little if they don’t make an effort to get that cost information, but we can’t control other’s behavior, we can control ours. We can make it a habit to present management with cost/effort information. Of course if management consistently refuses to use that information, think about finding another employer, especially if you get blamed for project delays. But stop whimpering that management makes unreasonable demands when they don’t have cost information because we haven’t given it to them.

In the Solr/Lucene world, this often manifests itself as endlessly tweaking how Solr returns results, based on someone glancing at the results and saying, “that’s not right, we’d get better results if we…”.

What do I mean by “undefined”? Well, unless you have some objective measure of search “goodness”, you’re just guessing. Even worse than guessing is the fact that the very same person can look at the very same results on two different days and have different ratings of “goodness”. And I haven’t even mentioned the problems with trying to satisfy two different stakeholders!

If I’m going to pound the table about something here, it’s defining your problem before you implement the solution, sometimes known as “the XY problem”. People jump to implementing a solution for a problem without understanding the problem, when in fact the problem is something that would be far better addressed by a different approach.

Whenever you find yourself saying “sure, we can do that” when a stakeholder (or anyone else for that matter) suggests a solution to the problem (e.g. “We’d get better results if we didn’t stem”), pause. Then stop. Then take a deep breath. Ask “Why do you think so?” Then look at your data. Then spend a few minutes thinking about the unintended consequences of the change. Then consider whether there are better solutions out there. Then think about actually implementing the suggestion. Or offer an alternative.

Never, never, never go straight back to your desk and start implementing the suggestion without spending at least a few minutes defining the problem and considering alternatives. Especially alternatives that would take far less time to implement and give results that are “close enough”. Going after that last 5% “better” is rarely worthwhile. I suggest you have far bigger problems that could use attention than the last 5%. Especially if you can’t measure “better” objectively. And even if you do have an objective measure, is a 5% improvement worth your time?

Yes, this is a “wetware” problem. It doesn’t feel productive for engineers to spend time running around to stakeholders asking “Is this worth it?” Who knows, it might even lead to more meetings (shudder). You’d rather spend your time doing something interesting, like programming. But it’s vital to:

• Product management
• Getting your product out on time
• Your company generating, you know, revenue; the yucky part of the business that…um…pays your salary
• Otherwise justifying your organization spending money on techies like you

There, I think I’m finished with this rant. It’s been sparked by the number of times I’ve seen (and been involved in) solutions to problems that either didn’t really address the problem or were expensive and resulted in minimal gains. The more I’ve cultivated the habit of pausing and thinking for just a few minutes about the problem rather than the first solution offered, the more often I’ve seen that there can be great benefit to the organization in making sure the various stakeholders understand the costs involved in implementing changes. And consequently great benefit to me. I spend far less time doing work that turns out to be of minimal value and more time doing things that count.

Engineers are like that.