The hardest thing about programming – part 2

Okay.  In my previous post, I said that the hardest thing about programming is [getting good requirements].  I also talked about the symptoms of not getting good requirements.  So, let me take a minute to talk about some of the problems that stand in the way of getting good requirements.

To get good requirements, you need 2 primary things:

  1. a good requirements-giver
  2. a good requirements-taker

If you have both, you are golden.  The requirements will flow nicely and everyone will win.

So, if you do not have a good, experienced requirements-giver, you might be able to make up for it by having a very good & experienced requirements-taker or vice versa.

Before I had worked with a really good & experienced requirements giver, I had no idea what I had been missing.  When I finally met one, I was astounded.  Seriously.  She knew all of the right answers to give.  She knew what questions I was supposed to ask (even if I didn’t).  She told me what features affected timelines and which were high priority and which were optional.  She understood the features of the technology that I was using and which ones were the right components.  Also, she made no qualms about saying what she knew and what she didn’t know.

After that project, I went back to working with ordinary people who were giving requirements and the difference was IMMENSE!  I realized how weak my requirements were.  I really had to dig down and think about the questions I was asking and the answers I was getting.  I had to really work on coming up with better questions until I got a good answer and I had to persevere until I got the right answers.  There were some times when I had to use differing approaches to make sure we were communicating effectively.  It was a lot of work.  It was quite frustrating at times, for both of us, but it paid off.

A few years ago, I gave a lunch & learn presentation on this topic.  At the end, a few people from my audience said “So, you haven’t actually told us what to do to be good requirements takers.  You only said it was much more difficult than it sounds and acted all ominous and stuff.”  I don’t think it helped much when I said that it wasn’t possible to turn people into good requirements takers over a 1-hour lunch & learn and I was sorry if I gave that impression.  That does seem to be a common attitude in society today, that anybody can be awesome without trying very hard or studying or persevering.  I’m such a balloon popper.

Since then, I have tried to come up with a better answer to the question “how do we gather better requirements”.  So, try this one on for size and see if you have anything to add:

Skills that are necessary to give/receive good requirements:

  • An analytical mind – You must analyze a process and de-construct it before you can accurately document it
  • Ability to abstract – You need to imagine how to teach someone else how to do the job without saying “just follow me around and do what I’m doing” (waaaay more difficult than most people can imagine)
  • Some familiarity with technical jargon and/or problem-domain jargon – Many jobs use special terms (jargon) to communicate effectively, using fewer words.  Knowing this jargon can make it much easier to communicate.  Snubbing this jargon or complaining about it just kills productivity because you have to teach the other person the jargon (and hope they are willing to learn) or learn a special set of non-jargon terms so you can communicate without using jargon, which is really awkward and un-productive.
  • Knowledge of the toolset (preferred) – Knowing the strengths/differences of your toolset can be the difference between looking like a “B student” and an “A student”.  A good system will do its job, but a great system will leverage the strengths of the toolset or stretch it in ways that turbo-charge its usefulness.  True awesomeness!
  • A serious grasp of responsibility – If you feel like this is someone else’s job and you just want to get it over, then you are likely to be hasty and sloppy.  If you really take it seriously, you will be driven towards excellence and it will show in the end-result.
  • A good example can go a long way – It is easier to change an existing document or make something that looks like it, than it is to start from a blank sheet of paper.  Making a solid example also helps set expectations before-hand.

I’d like a few more items to add to this list.  Please speak-up.


About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in Methodology. Bookmark the permalink.

One Response to The hardest thing about programming – part 2

  1. SomeName says:

    Useful. Thanks.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s