Decision Trade-offs

As I was catching up on my reading last night, I found this post .  Peter Torr was talking about “always making the wrong decision”, and asking for forgiveness in advance for making *someone* unhappy when their project is released.  (Peter works on the Visual Studios Tools for Office team.  In his post he also mentions a number of his teammates who are also blogging, I’ll have to check them out.)

I’ve certainly been in the situation many, many times in my career where there wasn’t a clear right answer.  For example, the times where a change would benefit the vast majority of users, but would really inconvenience a small number of users. Those types of trade-offs are painful for exactly the reason that Peter talks about – there’s no right decision, only hopefully (but always subject to much debate) a better decision. Unfortunately, sometimes it’s just the decision, there’s nothing good or better about it, but you still have to make one (because not making a decision is also making one.)  And  the pain doesn’t always come from trade-offs between user segments… decisions involving business needs and user needs trade-offs are just as hard.  Sometimes, for example, you have to work on plumbing in order to enable the future.  And in order to stay focused on getting all the necessary plumbing in place, you have to forego features or enhancements that your users really want.  That’s the situation we’re in at MSDN Online right now.  We have a site publishing and management system that consists of many discrete tools, sometimes hooked together and sometimes with manual steps in between.  We’ve got Phase I of a new publishing system project under our belts, and Phase II* is underway.  In the meantime, though, our internal users (our coworkers!) are crying out for help.  And of course we want to help them. Looking for a good line between making as much forward momentum as possible on the big project that will make major improvements across the board, and making changes to existing systems that will make the users’ lives easier now but is potentially throwaway is hard because the line is gray, and wobbly, and can be really, really hard to see.  And so we approach it one step, one request, one project at a time, always looking for the better decision.

*This project is one of the most well-planned projects that I’ve seen in a while.  Notable is the concerted coordination and communication across a number of PMs, as well as the cohesiveness and intentionality of the team.  I had the opportunity to act as facilitator for their Phase I Project Retrospective, and was impressed with their firm grasp of where their opportunities for improvement were/are, as well as where they were/are already doing well. And now I see them making changes based on their Project Retrospective results; it’s thrilling, really, to work with so many people that are just so damn easy to respect.

Comments (3)

  1. Mike Dimmick says:

    This is going to sound really picky, I know…

    It looks like you’ve got a double character set conversion going on somewhere – Windows-1252 to UTF-8 to Windows-1252 again, I think. You can see this in the WS-Addressing spec that recently got posted: see, section 4, second paragraph, right after <wsa:FaultTo>.

    An ellipsis character (U+2026) has got converted to the sequence A-with-tilde comma A-with-circumflex ellipsis due to this conversion.

    I reported this once before with regard to the Visual Studio Roadmap (same problem); it was fixed there by changing the offending sequence simply to three dots.

    It seems to affect any character with a Unicode code point greater than 255.

    Sorry for the techy detail!

  2. lauraj says:

    Thanks Mike. We’re editing the document, and I’m also following up to make sure it’s not a systemic issue. Thanks for letting me know!