Under the Radar
I think I'll ease you all into the life a software engineer with a tail of requirements. Hopefully if you're on a well run project, you'll have a list of requirements that your software has to fulfill. The more detailed they are, the better things tend to be. Recently I was assigned to complete a requirement on a project which had fallen through the cracks. The project is nearing completion, and somehow this one never got assigned.
As I was reading through it, I realized that the person who wrote it must have been smoking something, because I had no idea what I was actually supposed to do. So, as you always do in this sort of situation in a large company, I called a meeting. We got a half dozen people in a room and for an hour we went around about what we really were trying to accomplish... just trying to understand what was written on this piece of paper. Finally, after coming to an understanding about what was being asked, the person who originally wrote the requirements was told to rewrite them so we could understand them as we talked about in the meeting.
You'd think that would be the end of this tale. A new draft is sent out, and everyone agrees that they now look good, so I start writing some code to accomplish what is asked. Then two days later, when I'm almost done, an "updated copy" is sent out, with a few minor "tweaks". I read the new document only to see that these new requirements are quite different than the old ones. I replied back asking if it was just my imagination, or were these different. His response? "I just reworded them a little". So I reread them, and then responded back that these were in fact quite different, and listed the differences, carbon copying several people in on the email. Was he trying to sneak something under the radar?
This is a real danger. More projects are delayed, and bugs introduced into software by "requirements" snuck under the radar, so I called him on it. After talking to my project manager, I found out that he had ok'd it with the business after several hours of back channel discussions. Why didn't he just say - after discussing it with so and so, the business agreed that we want it done this way? Why lie and say "I just reworded it". And people wonder why so many software projects go over budget.
As I was reading through it, I realized that the person who wrote it must have been smoking something, because I had no idea what I was actually supposed to do. So, as you always do in this sort of situation in a large company, I called a meeting. We got a half dozen people in a room and for an hour we went around about what we really were trying to accomplish... just trying to understand what was written on this piece of paper. Finally, after coming to an understanding about what was being asked, the person who originally wrote the requirements was told to rewrite them so we could understand them as we talked about in the meeting.
You'd think that would be the end of this tale. A new draft is sent out, and everyone agrees that they now look good, so I start writing some code to accomplish what is asked. Then two days later, when I'm almost done, an "updated copy" is sent out, with a few minor "tweaks". I read the new document only to see that these new requirements are quite different than the old ones. I replied back asking if it was just my imagination, or were these different. His response? "I just reworded them a little". So I reread them, and then responded back that these were in fact quite different, and listed the differences, carbon copying several people in on the email. Was he trying to sneak something under the radar?
This is a real danger. More projects are delayed, and bugs introduced into software by "requirements" snuck under the radar, so I called him on it. After talking to my project manager, I found out that he had ok'd it with the business after several hours of back channel discussions. Why didn't he just say - after discussing it with so and so, the business agreed that we want it done this way? Why lie and say "I just reworded it". And people wonder why so many software projects go over budget.