I am a computer programmer by profession. In my personal time, however, I am a computer programmer. The difference between the two: requirements (or the absence thereof).

In my industry, software requirements are considered a big deal by nearly all of my users, especially the paying kind. In the 5 years I’ve been working in this industry, I’ve learned five lessons that I’d like to share with my readership (yes, all 3 of you, not counting family).

Lesson 1: Requirements Change

Duh. Everyone knows this. If you’re a great computer programmer, you cope with it by writing flexible code and having a positive attitude. What people don’t know is that changing requirements are really just a symptom of a deeper problem, which I’ll cover later. The lesson here is that you must be flexible, but you already knew that. So, on to…

Lesson 2: Requirements are a Front

Software requirements exist for one reason: People are sick of crappy software. Several years ago, some well intending but misguided people set about to solve the “crappy software problem” by creating a process to control software development more closely with carefully crafted and well managed requirements. Who can blame them? If users knew how to write good software, they would do it themselves. They certainly wouldn’t pay some “socially awkward” person who yammers about closures and list comprehensions. But since they don’t know how to write software, they have to manage those who do. I’m referring here to “the paying kind” of users I mentioned before. I should point out that I’m not talking about shrinkwrap software here, but rather custom development projects with big price tags.

So what’s the front? The front is that the customer knows what he wants, and he desperately wants to communicate that to you, but he only has this crippled 1200 baud modem of a language called “requirements.” This puts you, the programmer, in interpreter mode. Your job is to find out what he really wants and translate that into a usable product. This leads me to…

Lesson 3: You, The Programmer, Must Control the Requirements

Because great programmers recognize their role as an interpreter, translating requirements into what the customer really wants, and translating that into code, you have to be in charge of the requirements. This means that once in a while, you have to go out on a limb and say things like, “Mighty customer, sir, your requirements document says A, but I think you might like B better.” Sometimes you might even have to implement and demonstrate the feature to him first. This is a risky place to be, but it’s where you have to go if your software project is to be successful. This means you actually have to think about what the customer is asking for. Yes, great programmers don’t just translate requirements into code, they go behind the requirements and they control the requirements by gently nudging them in the direction that the customer really needs.

This means you’ll be wrong sometimes. That’s the price you pay to have a successful software project. If you find that you are wrong too often, you probably don’t understand your customer well enough, and some homework is in order. Stop controlling the requirements until you understand your customer fully.

By the way, very few programmers can do this right all the time. I only know a few, and I’m not one of them yet. Most programmers will simply translate requirements into code, and then get very upset when their product is thrown away or rejected by the customer (even if it “satisfies” the requirements”). This is all too often the case because the requirements were bogus in the first place. Truly great programmers, on the other hand, will not only satisfy their customers, but will exceed expectations by delivering a product that gives the customer something they didn’t even know they needed (pay attention managers: that means more revenue), but now can’t live without.

Let’s take an example from the shrinkwrap world: A couple years ago, no one would have thought they needed a $500 cell phone, but now millions of people just have to have one. Why? Because Apple figured out what people really wanted, before people even asked for it. Do you think some Apple customer handed Steve Jobs a requirements document to build the iPhone? Yeah right.

Lesson 4: The Only Real Requirement

In the end, there is only one real requirement, and it’s quite simple: The customer should get what he wants, and also what he needs. Sometimes you, the programmer, have to help the customer realize that what he wants is not what he really needs, or that what he needs is above and beyond what he wants. This takes people skills. Some customers even want something that is totally at odds with what they need. These people are rare in my experience. You may have noticed that I used the word “gentle” above. That is for these customers.

You have to go behind the requirements to figure out the real needs of your customer. If you don’t, you will fail, even if you follow the requirements to the letter. I should say: Especially if you follow the requirements to the letter. In my experience, implementing the requirements is about 30% of the total effort on a software project. The other 70% is spent discovering and implementing the things that the customer really needs.

Lesson 5: Good Requirements Can’t Replace Good Programmers

Some people seem to think that if you write your requirements well enough, you can afford sub-par programmers. This is simply not true. I don’t care how good your requirements are. I don’t care how much work you did to make them perfect. If you hand them over to crappy programmers, your project will fail. Period.

The only way to run a successful software project is to employ the best people. Never think that if you apply enough rigorous process and manage requirements well enough that you can compensate for having crappy programmers on your project. Nothing can compensate for crappy programmers.

Remember what I said about 30% vs 70%? Good programmers make up the 70%, even if you have perfect requirements (hint: you don’t have perfect requirements).

Happy Coding!

Now that you know what I know, get out there and find out what your customers really want! Oh, and don’t expect to find the answer by just asking, “Hey, what do you really want?”

Good luck!

P.S. I mentioned a “deeper problem” in my first section. Did you figure out what it is? I hope so.