Understanding Requirements
Understanding Requirements is probably one of the most important aspects of programming. In the 1989 movie, Field of Dreams
If you understand it, you can code it
Often there is a total communication breakdown between the analyst and the programmer. That is because the analyst that wrote the functional requirements
“So I need to create a class of type Sales Order that will enumerate the collection of order lines and execute a non-query to the database to insert the record for the linked Sales Order Header ID?“
Sitting across the person that made this statement is a very nervous, wide-eyed analyst. Okay, so perhaps this isn’t the best of examples, but you get the idea. Sometimes I see programmers (especially junior programmers) that sit in a meeting where the requirements are being discussed, and I can see that this guy or girl have no clue what everything means. They are however (hopefully) fevereshly taking notes.
In the hot seat
This reminds me of the time that I had an 8 am appointment at a client in Johannesburg. Traffic is always a nightmare and I made sure that I had read through the requirements documentation my manager had given me the day before. Needless to say, the GPS took me on the wrong route and I ended up being late for the meeting. When I arrived, the meeting had just started and I was the last to sit down. These guys then started discussing the requirements for the proposed system, and I soon realized that what I had read the night before, was absolutely and utterly a totally different system. My manager forgot to give me the second requirements documentation for the second system they needed.
I decided to bunker down and listen VERY intently to what was being discussed, in the hopes of catching the gist of it all. Then, the horror of all horrors happened. My manager turned around and asked me for my opinion. I broke out in a cold sweat, I could feel the whole boardroom looking at me in expectant anticipation. For the very first time in my life, I was totally and utterly lost for words. Mumbling something about them having covered all the bases, and that the proposed solution sounded solid, I was lucky that the finance guy interrupted with a question to one of the other attendees. (At least I redeemed myself when they started discussing the system I had read the requirements documentation of.)
Speaking up
So many times, I see programmers with that look on their faces… the one I had on my face in that meeting. What I can’t understand is that this behavior is so prevalent in junior programmers. Even if you ask them if they understand what is needed or what was discussed, they often say ‘Yes’. So the ninth tip I would like to share is that, if you understand it you can code it. End of story. We as programmers should be comfortable with our programming skills. In fact, I almost would like to say that what we understand from the requirements of a new system should translate directly to code within our minds. We should be able to conceptualize the application before we write a single line of code.
Going forward
Never be afraid to ask questions. If you don’t understand, ask. You are after all translating business jargon into C# or Java or whatever language you code in. Reversing these roles (in other words, you talking C# and an analyst needed to draw up a functional document from that) I will guarantee you that the analyst would have a couple of questions for you. In fact, what we as programmers often need to do it quite difficult. Understanding what you need to do is essential. You will see, once you know that, the code will come naturally.
Reference: CommLab India
