Gathering Requirements

“Gathering Requirements” is one of the most dreaded phrases in software development. Before starting a new project you have to go through the “gathering requirements” phase. When you’re “gathering requirements” it means you can’t start building yet. It means you can’t do any of the fun stuff like buying servers or writing code. Or downloading new frameworks that all the cool developers are using. It means you have to stop, sit down and think hard about all the things that could go wrong. It means discussing with the customer what they actually want. It means thinking with the end in mind and determining the path the entire journey will take, with error checking and documentation. It means stop daydreaming about how great this will be and actually come up with a plan.

It means you have to answer all the following questions:

  1. Who is it for?
  2. What is the cost?
  3. What exactly should this project/item do?
  4. How much time will it take?
  5. What is the expected outcome?
  6. What could derail our plans?
  7. How will we finish if something doesn’t work out?
  8. Is this the best use of time/money/effort?

The reasons for doing this are as obvious as they are boring. First, if you start all your adventures with only a half baked idea about what you need you’ll waste too much time and money. You’ll quit half way through because it’s taking too long. You’ll discover you don’t have enough money. You’ll discover you didn’t need to print CDs. You’ll discover that the expensive producer you hired didn’t want to work that hard and now you’re half done and out of money. Or just as bad, you finished something that doesn’t meet your requirements in the first place.

“Gathering requirements” isn’t the thing you do before “the project” can start. It’s the most important part of “the project”. The thing that makes the rest possible. So don’t dread it. Go get those requirements.

The Story About the Thing That Happened

There’s always two things. There’s the thing that happened. And then there’s the story you tell yourself about the thing that happened. It’s tempting to think that the story you tell yourself about what happened is the thing that happened, but it’s just the story. And the story is up to you.

Consider a low paying or otherwise less desirable gig. Here’s two stories you can tell yourself:

1. This leader is a jerk and he’s underpaying us. The music is no good. I really shouldn’t be here and this is beneath me. Why don’t I get called for the big gigs? I play better than those other guys. It’s all politics.

2. This gig is easy. I may as well focus on a couple of little things on my sound and get a few bucks in my pocket. Won’t be here for long so let’s just get what we can out of it. Ain’t much money in this kind of work so I’d better be on the lookout for the next thing.

A self help guru is probably going to tell you that story number two is the “true” one. That’s the wrong answer. They’re both true. The second one is just more useful. And if you have a choice of stories to tell yourself, why not pick the most useful one?

Your Toolkit

Think about your answer to this question:

If someone from the 1950’s appeared today, what would be the most difficult thing to explain to them about today?

There are lot of answers to this question. It showed up on reddit a few years ago, and the favorite answer was this:

I possess a device, in my pocket, that is capable of accessing the entirety of information known to man. I use it to look at pictures of cats and get in arguments with strangers

Our tools take a big part in determing how we do our work. It’s worth it to take time and decide whether it’s working or not.

How productive are you when on a web browser vs. opening up a new note in Evernote? How useful is the content you post to Facebook vs. what you write in a lengthy email to a colleague? Or a blog post vs. a tweet?

In the music business our most common tool is our instrument. The second most common is probably a computer. For a tech worker the text editor or IDE. Are we setting up our tools to allow us to work at our best. Or are we allowing the tools to shape the way we work?

Programmers everywhere will tell you that your choice of programming language has a big impact on how you view the task of programming. Methods that are obvious in one language are rare in another. The programmer who spends all their time in one language will display a strong preference for whatever is most common in their preferred toolkit. The toolkit is determining the results.

For musicians, we do the same. If we spend most of our time playing an instrument, we avoid writing and arranging. If we do our socializing on Facebook we’ll probably use it as our marketing tool of choice. If we write music in Sibelius or Finale, we’ll almost never use tricks that aren’t easy to notate. If we don’t learn how to read music we’ll never write songs with complex counterpoint. Or use complicated forms that are hard to remember.

We are craftsman. And a craftsman cares about their toolset. What devices, analog and electronic, are you using on a regular basis? What’s your hammer and screwdriver?

© 2017 brianowenmusic.com