I am a computer programmer by profession. In my personal time, however, I am a computer programmer. The difference between the two: requirements<\/b> (or the absence thereof).<\/p>\n
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).<\/p>\n
Lesson 1: Requirements Change<\/b><\/p>\n
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<\/b> be flexible, but you already knew that. So, on to…<\/p>\n
Lesson 2: Requirements are a Front<\/b><\/p>\n
Software requirements exist for one reason: People are sick of crappy software. Several years ago, some well intending but misguided people<\/a> 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<\/a> here, but rather custom development projects with big price tags.<\/p>\n 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<\/b> and translate that into a usable product. This leads me to…<\/p>\n Lesson 3: You, The Programmer, Must Control the Requirements<\/b><\/p>\n Because great programmers recognize their role as an interpreter, translating requirements into what the customer really wants, and translating that<\/b> into code, you<\/b> 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<\/b>, but I think you might like B<\/b> better.” Sometimes you might even have to implement and demonstrate the feature to him first<\/b>. This is a risky place to be, but it’s where you have<\/b> to go if your software project is to be successful. This means you actually have to think<\/b> about what the customer is asking for. Yes, great programmers don’t just translate requirements into code, they go behind the requirements<\/b> and they control the requirements<\/b> by gently nudging them in the direction that the customer really needs.<\/p>\n 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<\/b>.<\/p>\n 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.<\/p>\n