Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2573 posts at DZone. You can read more from them at their website. View Full User Profile

Stop being so agreeable!

  • submit to reddit
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.

This post is authored by Eric Erickson, an Apache Lucene and Solr committer

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.



Alex(JAlexoid) ... replied on Wed, 2011/11/16 - 9:46am

The simple answer developers should be always reminded to reply "I/We will note that and will see what we can do about it". That is called expectation management.

In fact, the sales people should always have a technical person sitting in the corner at negotiations, with whom they can talk to. And their reply should be teh same as above to new feature requests.

A client that gets what he needs and on schedule, will come back. The one's that don't or raise requirements at the last moment you don't want.

Being strict on requirements and needs save you and the client time and money.

Roger Lindsjö replied on Thu, 2011/11/17 - 4:22am

When I started working as a software developer I always thought that if a person told me to implement a feature a certain way or that I shuld use specific technology that this was a statement where the pros and cons had already been wighted against each other. Experience has told me that this is rarely so! Even now I sometimes am too optimistic when assuming the level of understanding of the problem.

I was recently involved with a problem where long lived session data was part of URLs and this session contained user id. However, should the site be indexed by a search engine, then any this url would be used by all users finding the site via a search engine. Not a huge issue but it did really screw up statistics (hey, here is a user which moves around the world in the matter of seconds and changes device several times a second).

The obvious solution was to use cookies, but I pointed out that if we did, then we would not be able to support clients cookies. After working on other things another team had made changes and one of the sales persons talked to me about it.

Him: Now it's fixed, we will deploy the fix shortly and then the statistics will be ok again.

Me: Ok, so what happens with clients not supporting cookies?

Him: Not a problem, the flow checks if they support cookies and if not they are redirected to a page telling them that cookies are required.

Me: But what about search engines (the ones causing the problem from the beginning)? Now most of them will only index your "cookies required" page.

Him: But surely all big search engines support cookies when checking the site.

What happened here was that nobody else thought about the drawbacks with a site that requires cookies. Not enought thinking, too much doing.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.