Good Advice Scorned


I thought it might be interesting to start a discussion about what is possibly the number one frustration of the performance architect:  What do you do when they won’t listen to you?

I’m sure you’ve all faced this, you lay out the situation, you show them the numbers and your team still won’t take the actions needed to avoid the forecasted problems.  Then what?

Well, you could put on your best Vincent Price voice and read them this poem:

Once, twice, three times warned,
And each time good advice you’ve scorned.
See the perf disaster loom,
Now you face your project’s doom!

That’s certainly a dramatic attention getter, but is it likely to help?  Err, probably not — unless you’re trying to get yourself a whole lot of time away from it all.

So what do you do?  Well, one reason I’m making this posting is I’d like to hear what sorts of things you do.  But let me tell you what I do:

  1. My job is to help my team make better decisions, it doesn’t end the moment they make one that I don’t think is the best, if anything that makes my job all the more important going forward.
  2. If we’ve decided to take a hard road then it’s all the more important to understand what the likely outcomes are going to be and start planning for them. For instance:
    • Can we clearly articulate the costs we’ve decided to pay (performance or otherwise) so we all know what they’re going to be.
    • Can we make afforances for the costs so that those costs are easier to bear?
    • Can we mitigate the costs at all?  
    • Can we prioritize the problems/costs we’re likely to face so that we can address the ones that matter the most if not all of them?
  3. Your team may have settled on a plan other than the one you endorse but perhaps you can find other ways to gain some of the benefits of your original plan.

The long and the short of it is that we all sink together.  Some of the choices won’t go the way I would like — that’s both expected and healthy — that just makes the adventure more fun.

Comments (5)

  1. Mike says:

    I’m know to be quite outspoken, and I sometimes get shit for that, but I also always have knowledge to back up such "controversial" outspokennes. If you’re good enough, management listens to you. If not the first time, display a "paper trail" of what you told them the last time, and display the disaster *they* created by not listening to you.

    I know, I know, it’s not good for your carreer ladder in some places (MS included I guess) to display in public "My boss, and his boss (and so on) are idiots, and here you have the exact numbers and their decisions to display it is so". Who cares. They have a track of being idiots, and you have the proof to display it.

    If they don’t listen the second time (and the first disaster is theirs, not yours, as you have saved records of this – right?), and their masters think they are doing good; time to look for a better job. You can never convince fanatics without reprogramming them. It’d be like trying to reprogram a brainwashed McDonalds employeee to "You know, McDonalds might actually not be the best food on the planet".

    Speaking of cost – it seems you only think of *your* costs. Think about the potentially *hundreds of millions* users that have to pay the cost of you not properly optimizing. One second to you, assuming 100mil Windows-PC’s a day paying this extra single second, results in almost 30.000 lost man-hours per day. 30.000 man hours is for a 40-hour worker around fifteen YEARS. That’s what not shaving off that 1-second delay deprives the world each day!

    If you want to talk about cost, then compare those fifteen years/day lost to the "cost" of producing properly optimized code…

    Feel free to use this when talking to your boss, or whatever level you reach in the hierarchy replacing good-for-humanity with even-more-riches-for-MS. Remind them of the near-monopoly status too.

  2. Cheong says:

    Mine is simple. I give warnings. If they neglect it, I’ll keep my mouth shut (also for other aspect of the project).

    If they found me completely silent on comment/support of the project, they’d know something wrong is there. (Applicable only if you’re the only one in the company who research for how to do the technical part of the project)

  3. chrisb says:

    My general role isn’t quite targetted at the area you’re after – I support/mentor the junior-medium level devs for the most part…

    I usually sit down with people and get them to verbalise what it is theyre trying to do – forcing them to do so usually helps them to see obvious flaws in their plan.

    If they don’t see a problem while talking it over, I can usually drop the suggestions/explanations of better ways to do it into the conversation and so avoid the very natural defensive attitude everyone can take with "you’re doing it wrong" type confrontation.

    If they still do it wrong, I just let them make the mistake and learn from experience.  If it was a big enough problem, they’ll have an issue in perf testing or whatever and will come back to me for advice on how to sort it out  –  Yes I realise I’m allowing to waste the time once, but after they’ve tripped over and then learn the better ways they usually dont make the mistake again..

  4. You have a wonderful attitude, Rico. If you give what you believe is good advice, the advice is ignored, and the inevitable happens: be noble, not petty. Rubbing salt on wounds is not productive.

    If you consider yourself part of a team, and not an isolated individual, team failure is a collective thing for everyone in the team, even if one person tried to prevent failure and was ignored. Good advice will always be ignored at some point. That is simply the way teams operate.

    If you find yourself constantly cleaning up after other people, that is a different problem — there are ways to avoid that too, without sounding arrogant.

  5. laurien says:

    "If you want to talk about cost, then compare those fifteen years/day lost to the "cost" of producing properly optimized code…"

    When making these decisions, the long-time cost to the customer only factors in if there is very strong competition so ignoring it might lead to losing a sale. It certainly doesn’t factor directly into the cost discussion regarding the project itself, nor should it.

    The goal of the software producer is to produce something usable the customer will buy, the goal of the customer is to get something that will satisfy his needs and wants. They are necessarily not the same, but each side gets a little bit of what they want: the producer gets profit less than what it really wants but more than they had before, and the consumer gets a product less than what he really wants but better than what he had before.