software requirements again, take 483
in [Perl]
|
From: ccc31807 on 1 Apr 2010 11:27 We have an institutionally critical process that consists of a back end (getting data from various sources and creating input files to generate the documents) and a front end (preparing and sending the documents from the input files.) We do this multiple times a year, and it's task based, with single individuals performing multiple tasks (from one to about six), and it generates hundreds of task documents institution wide. Several years ago, I wrote the back end, and it's worked perfectly. A month or so ago, I was given the front end process as well. The due date was Tuesday a week ago, nine days as I write. It was a week late, I finished it last Tuesday, a week late. (I had to wait on input from other people to finish the job, and they were tardy getting back to me.) About 3:00 p.m., I got a call from the manager in charge who told me that the software wasn't doing some of the documents correctly, some weren't prepared at all and some were prepared wrong. Four documents were affected out of 489. After looking at it, I saw that the problem was the some tasks could also be performed by multiple individuals, and my scripts only allowed for tasks to be performed by one person. (The main database we use contains a 'task' table, with one row per task and the individual responsible for the task. It doesn't not contain information about multiple individuals per task.) To correct the problem, I literally had to start from the very beginning -- the first problem is that the data now has to come from two tables that do not share a common key -- and revise the database queries, data formats, data structures, etc. I griped (to anyone who would listen) that this requirement to generate task documents accounting for tasks to be performed by multiple individuals was a critical functional requirement, and I DIDN'T FIND OUT ABOUT IT UNTIL THE SOFTWARE WAS A WEEK LATE! It wasn't that this requirement wasn't known, these documents have been generated for years, the manager wasn't aware of the details, it just worked, and assumed that I knew the details. The guy who did the front end had his methods for accounting for this requirement, but he wasn't available. I'm guessing that he made the corrections manually, but he had access to sources of data that I do not have. It mystifies me that a critical requirement of this nature wouldn't be specified until after the software had been written, and when the software was already late. Apparently there's some universal law that states this, but I don't know what the law is, or why the law is. I know what some on c.l.p.m. will say -- don't correct the software but comply with the wrong requirements, or get another job, but these aren't realistic. I'm just blowing off steam, decompressing. I've been pretty beat up over the last three weeks, I'm about to take the rest of the week off, and I just wanted to relate my experience. Thanks for listening. CC.
From: Charlton Wilbur on 1 Apr 2010 15:19 >>>>> "cc" == ccc31807 <cartercc(a)gmail.com> writes: cc> It mystifies me that a critical requirement of this nature cc> wouldn't be specified until after the software had been written, cc> and when the software was already late. Apparently there's some cc> universal law that states this, but I don't know what the law cc> is, or why the law is. This is not mystifying. It has to do with the people who do the job every day not thinking about the details, because they're internalized. The problem is that this lack of communication has somehow become *your* problem, and you seem to have accepted that. Doing that just sets yourself up for more frustration and more failure. Charlton -- Charlton Wilbur cwilbur(a)chromatico.net
From: J�rgen Exner on 1 Apr 2010 16:50 ccc31807 <cartercc(a)gmail.com> wrote: [Story of long suffereing snipped] >DIDN'T FIND OUT ABOUT IT UNTIL THE SOFTWARE WAS A WEEK LATE! >It wasn't that this requirement wasn't known, these documents have >been generated for years, the manager wasn't aware of the details, it >just worked, and assumed that I knew the details. The guy who did the >front end had his methods for accounting for this requirement, but he >wasn't available. I'm guessing that he made the corrections manually, >but he had access to sources of data that I do not have. > >It mystifies me that a critical requirement of this nature wouldn't be >specified until after the software had been written, and when the >software was already late. Apparently there's some universal law that >states this, but I don't know what the law is, or why the law is. So, what was the feedback from those people when you presented your spec? Did they miss the flaw, too, and signed off on the misguided concept? And what about during the testing phase? Yes, testing should primarily check if the code complies with the written specification, but at least in the later parts when actual users check out if the progam meets their needs, then they should have noticed that critical functionality is missing. Honestly, looking at your long history here in this NG you are in this way over your head and while you are trying to make up with a lot of enthusiasm and determination it is hard to overlook that you are missing basic skills for the job you are supposed to do. It's like you know how to use a hammer and a saw and you are actually rather skillful with those. So you are building garden sheds and the occasional deck or gazebo and you turn them out on demand, in decend quality and functional. But that doesn't automatically qualify you to build a house or like in this case an add-on garage with mother-in-law. Those projects simply require planning, organization, and preparation skills (aka project management) which you don't have. And, if you excuse me for saying so, which you have shown little interest to learn or to adapt. It's really the same story over and over again: you need to get your nose out of the editor and stop worrying about those pesky syntax errors. The actual coding part is only one small portion of the whole development process and you have to start looking at the bigger picture and understand development processes in context or things like this here will keep happening again and again and every single time you will get more and more frustrated. Now, I do understand that there are people who couldn't care less about project management and love spending all their day coding from dawn to dusk instead. Fair enough, there's nothing wrong with that. But based on your stories your position is not a position where you have the luxury to do that. There is nobody else who would provide this service for you, nobody you would talk with the users, gather and organize their requirements, organize your coding work, organize the schedule, testing, feedback gathering, and and and. Therefore you either have to grow into that role or find someone else to cover that role. Because as long as you keep applying the same non-functioning process you cannot expect the outcome to change for the better. jue
From: ccc31807 on 1 Apr 2010 19:40 On Apr 1, 2:19 pm, Charlton Wilbur <cwil...(a)chromatico.net> wrote: > The problem is that this lack of communication has somehow become *your* > problem, and you seem to have accepted that. Doing that just sets > yourself up for more frustration and more failure. I agree that the problem is lack of communication. As to the back end, my main database query used a table that had EXACTLY one person per task. As I mentioned, I have been doing this for years, and had ALWAYS submitted a data file with one person per task. The intermediate person, the one who is not available to talk to, apparently manually adjusted the data files, because the ultimate file, when delivered to the manager, was correct. In this case, the requirement that on a few occasions a multiple number of individuals could be assigned one task was 'unknown' in the sense that I didn't know it, and the managing executive didn't know it. I agree that the software had a bug, and the bug was my responsibility, but how do you protect yourself from 'unknown' requirements, in the absence of the person who actually KNOWS the requirements? CC
From: Charlton Wilbur on 1 Apr 2010 20:25
>>>>> "cc" == ccc31807 <cartercc(a)gmail.com> writes: cc> I agree that the software had a bug, and the bug was my cc> responsibility, but how do you protect yourself from 'unknown' cc> requirements, in the absence of the person who actually KNOWS cc> the requirements? There are dozens of books written on this, and understanding their contents is what separates a software engineer from a code monkey. The fundamental rule, however, is that before you type a single character of Perl you should have a clear, unambiguous statement, agreed to by the business owner of the process you're automating or facilitating, of what the requirements are for the phase of development that you're in. When you have that statement, then you can estimate how long it will take and what it depends on. Everything else is details. Your problem, professionally, is that you don't get that unambiguous statement, and if you do, and it turns out to be wrong, you accept the blame and vent here. So long as you accept the blame and fix it, the people in your organization have no incentive to change. If they get the requirements wrong, they just pass the blame on to you. As long as you keep on accepting it, nothing will change. Your responsibility is to make sure you understand as well as possible what the business process owner is asking for, and to give him what he asks for. His responsibility is to ask for what he really wants. There is no reasonable way for you to take on his responsibility, and your biggest problem is that you allow him to foist it off on you. Charlton -- Charlton Wilbur cwilbur(a)chromatico.net |