Share via

Good Advice Scorned

  • Article

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

  • Anonymous
    January 19, 2007
    The comment has been removed

  • Anonymous
    January 19, 2007
    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)

  • Anonymous
    January 19, 2007
    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..

  • Anonymous
    January 23, 2007
    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.

  • Anonymous
    January 24, 2007
    "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.