Tuesday, December 22, 2009

People Problems

I'm sorry to have to tell you this, but your job is to solve problems for people.

I don't even have to know what your job is, and I can still say that with a pretty high level of confidence.  Are you an engineer building bridges?  You're solving a problem for people who need to get across that divide.  Are you a cashier at the grocery store?  You're solving a problem for people who need to pay for their groceries (and for people who need to take money from people for groceries, double whammy).  And of course, are you a computer programmer?  You're solving SOME, maybe not very well specified, problem for your users.

It really doesn't matter how far removed from people you are, you're still solving problems for people.  You could be completely devoted to the inner most workings of the Windows kernel.  You're actually worse off!  You're solving problems for users who want to check their email, and programmers who want to write MS Word, and designers who want to make Windows look pretty, and marketers who want to sell Windows as the most stable ever, and finance people who want to show market growth, and the list just goes on and on and on...

Sometimes you are aware that you are solving problems for people, but maybe you don't really know what problem you're solving.  Like the grocery store clerk who is really nice and friendly and makes all the customers happy going through the line.  Maybe they think their job is to make you happy, but it's not.  The problem you want them to solve is to figure out how much money you owe, and take it from you.  And you want them to do it quickly.  If they can do that AND make you happy, then they are a very good grocery clerk.  If they only make you happy, then they just aren't very good.

A similar thing happens with programmers.  I frequently get confused and think that my job is to make high quality software and write high quality code and do good high quality design work.  But its not.  My job is to solve some problem my client has.  As long as I fix their problem, I've done my job.  Maybe I could have fixed their problem better with beautiful code I'd be proud to hang on my wall at home.  That would be a bonus.  But all I'm supposed to do is solve their problem.

That is, unless I'm actually supposed to be developing a long life product, which will require all kinds of future enhancement and maintenance and re-configuring.  In that case my job is to both solve the client's problem AND develop a strong software product.  These are two competing goals.

And that's the thing about People Problems:
  • They are never clear cut
  • They tend to overlap
  • They always involve trade-offs
They're not clear cut because frequently you don't know what problem your supposed to be solving.  Or there are a bunch of problems you're supposed to be solving and you don't know which is most important.  Or different people have different problems and you need to simultaneously solve them all.  Create an app for a user!  Create it in the time your managers wants!  Make the app a platform to build a product on for your boss!

And this is where the trade-offs start.  You simply can't HAVE your cake AND eat it.  See?  Once you EAT it, you don't HAVE it anymore.  Or if you HAVE it, then you haven't EATEN it.  See?  I just thought that up. Pretty good huh?

The "real world" is all about People Problems.  And People Problems inevitably lead to trade offs. And trade offs inevitably lead to disappointment.  For example, if you choose to make the code super high quality, you wont be disappointed, but your boss will be because of how much it cost.

The trick is to understand that above all you are solving people's problems.  Then understand that necessarily involves trade offs.  Then try to take a big picture view when deciding on how to make those trade offs.  Hopefully that will at least help you deal with the inevitable disappointment.  At least you'll know you made the best decision you could for the specific People Problem you were faced with.

Of course, you'll probably be disappointed when you find out later that you didn't have all the facts straight and your decision was based on faulty information or just information that has since changed.  But that's a whole different dimension of dealing with People Problems.


  1. You scared me there for a second into thinking you were going to become one of those uber pragmatist people who devalues quality in the name of getting stuff done. Fortunately you included this quote "That is, unless I'm actually supposed to be developing a long life product, which will require all kinds of future enhancement and maintenance and re-configuring."

    That said here's a little addendum to that. In my experience there is no such thing as a short life product that wont require future enhancement and maintenance. We frequently talk about how in "phase 2" we'll clean everything up or how what we are doing is "throw away." Problem is throw away apps and phase 2 have a lot in common with unicorns and Santa Claus. They are fun to think about and sometimes you can convince people they exist... but in reality.. not so much.

    Ok so that's not really fair.. I have been on a phase 2 before, and I have written truly throw away code, but 9 times out of 10 its an excuse to not create a maintainable product.

    Your right though that there is a trade off. The pride in is tends to drive us to over engineer at times and endlessly refactor. It's important to remember that "shipping is a feature."

  2. I've written throw away code before. The problem was that I didn't know it was throw away code at the time. The good thing was that I was able to leverage some of that throw away code to develop the new app that solved the ever-changing problems of my customer. I wouldn't have been able to do that without developing a decent product from the start.

    Captcha: "pultret"...Plural of poultry? Multiple groups of poultry. That would be a lot of poultry.

  3. Yeah, I'm with you guys. I believe there are almost no circumstances that truly warrant writing crappy code. But plenty of circumstances that warrant a certain trade off between how much time you have to do it right and how important it is to deliver it yesterday.

  4. strange though, when the same question, but say, affecting one's house, adding a new room, etc, you wouldnt just say "get it done, dont worry about 'quality'.. shouldnt software be the same?

  5. I wouldn't say "don't worry about quality" and neither does your client who wants software.

    But I would say, "That's too expensive" or "That'll take too long" or "My friend's house is this way" etc...

    The point is not that you shouldn't always want to write the highest quality software possible. The point is that trade-offs are real, and you can't just put the blinders on and ignore them.

  6. At the end of the day the decision will be made for you by you. It will come down to what your expected duration of involvement is, the goals outlined by your employer and how they match up with your client; assuming you are working in a consultative capacity, your own ability. If I have two weeks to write code and I need three to write it with all of the proper considerations as they relate to product lifespan, then guess what, unless I want to admit I can't get in done in two weeks I will solve the solution any way I can. If project management recognizes this as a strength and not a weakness then I can ask for a timeline revision and do the proper thing. At the end of the day it usually ends up above our paygrade.


Note: Only a member of this blog may post a comment.