software requirements again, take 483
in [Perl]
|
From: Jim Gibson on 1 Apr 2010 20:34 In article <83a0cba8-be79-42d6-a5fc-ec617e58734a(a)k19g2000yqn.googlegroups.com>, ccc31807 <cartercc(a)gmail.com> wrote: > 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? You get a set of written requirements and implement your program to comply with them. You will probably have to write the requirements yourself, since nobody else will think it is a worthwhile exercise. So you do it, then get sign off from your boss and the customer (end-user). Then, when the program fails to meet the end-user's expectations, you point out how the program actually complies with the written requirements to which they agreed. Then, you revise the requirements to match the user's expectations, modify the program to match the new requirements, and move on to the next problem, iterating until everybody is happy. It is not really a software bug if the program complies with its requirements. It is a requirements bug if the software complies with the requirements but does not meet the user's expectations. -- Jim Gibson
From: J�rgen Exner on 1 Apr 2010 21:48 ccc31807 <cartercc(a)gmail.com> wrote: >I agree that the software had a bug, and the bug was my >responsibility, No, it hadn't and no you weren't. The software behaved according to the spec, so there was no bug in the software. >but how do you protect yourself from 'unknown' >requirements, in the absence of the person who actually KNOWS the >requirements? By making sure that everyone who has a stake in the software attends the spec review and signs off on the spec. If he doesn't speak up then a flaw in the spec becomes _HIS_ problem, not yours. jue
From: J�rgen Exner on 1 Apr 2010 21:50 Charlton Wilbur <cwilbur(a)chromatico.net> wrote: >>>>>> "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. Amen to that, very well brought down to the point! jue
From: ccc31807 on 1 Apr 2010 23:08 On Apr 1, 3:50 pm, Jurgen Exner <jurge...(a)hotmail.com> wrote: Thanks for your comments. Please see below. > So, what was the feedback from those people when you presented your > spec? There wasn't any spec. The organization changed the written documentation, I was presented with the template, and was told to 'copy that.' Come to think of it, this probably WAS the specification. > Did they miss the flaw, too, and signed off on the misguided > concept? The previous documents were one per task. The new documents are one per person regardless of the number of tasks. I don't think anyone realized that a task could be performed by multiple people -- not even the big institutional database allowed it. The new format 'broke' the old automation and thus had to be rewritten. (The new format was dictated by HR, and the very first thing I brought up was why HR didn't consult with IT as to the workability of the new format, but HR doesn't have anything to do with IT.) > 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. Actually, this was discovered during the testing phase. I had sent the final set of documents to the manager and told her to examine them to see if they had error, which they did. At least this part worked as expected: test for errors, correct the errors, and test again. We tested until there weren't any more errors. > 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. This is the truth. I'm not a programmer but a database guy. I get to do programming because I am the only one who can, and I get to do it all: analysis, design, implementation, testing and debugging, deployment, and maintenance. It's a pretty good job, and I honestly don't feel much stress. > 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. That's right. This stretches me in terms of my skill level and capabilities. I'm not complaining about that at all. > 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. That's at least partially true, but in mitigation, the vast majority of my work consists of one off projects that literally can be completed from start to finish in an hour or less, and this environment does not inculcate the habit of planning, organization, and preparation. Most things are so simple that you can start coding from memory and never have to look at the Perl documentation or steal code from past scripts. > 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. I may have mentioned that I'm in a solo ship, literally. I've not a developer, or analyst, or even a programmer, but primarily a data munger. I'm pretty good at what I do, and have a good reputation at work for turning sow's ears into silk purses. > 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. All true. Again, in mitigation, my users sometimes don't know what their requirements are. It's a common occurrence for me to furnish information based on a written request that complies exactly with the written request, and find out that the user really needs something totally different. This happens maybe once in ten or twenty reports. I like my job. The pay is lousy, but it's low stress, lots of off time, not that much to do, I don't really have a boss that I have to report to, I get time off to go to school, I get to play with different technologies (including devoting a substantial time to learning other languages, most recently Erlang and Lisp), and have the respect of those who see what I do. Plus, I enjoy griping, and you will accept my apology if I sometimes favor c.l.p.m. with some of it. CC.
From: Peter J. Holzer on 2 Apr 2010 05:17
On 2010-04-02 00:34, Jim Gibson <jimsgibson(a)gmail.com> wrote: > In article ><83a0cba8-be79-42d6-a5fc-ec617e58734a(a)k19g2000yqn.googlegroups.com>, > ccc31807 <cartercc(a)gmail.com> wrote: > >> how do you protect yourself from 'unknown' requirements, in the >> absence of the person who actually KNOWS the requirements? > > You get a set of written requirements and implement your program to > comply with them. You will probably have to write the requirements > yourself, since nobody else will think it is a worthwhile exercise. So > you do it, then get sign off from your boss and the customer > (end-user). > > Then, when the program fails to meet the end-user's expectations, you > point out how the program actually complies with the written > requirements to which they agreed. Then, you revise the requirements to > match the user's expectations, modify the program to match the new > requirements, and move on to the next problem, iterating until > everybody is happy. The tricky part here is to make everybody happy. That not only means that the users get what they want in the end, you must also avoid frustration during the process. I think some points which help are: 1) Make clear from the start that the process is iterative. If both sides are aware that the spec isn't carved in stone but can and will be amended then it is much easier to do this. 2) Try to avoid passing blame. It isn't important whether the customer forgot to tell something or changed their mind or whether the programmer didn't ask the right questions or misunderstood the specs. The important thing is that a flaw has been detected and must be fixed. So write it in the specs and move on. (yes, some people always want a scapegoat for every problem, preferrably before they even know that there is a problem - but if they don't have to fear they they will be blamed they are also less likely to blame you) 3) Keep the iterations short. Firstly, that will enable everybody to remember what was discussed the last time and secondly, it avoids wasting much time by going far into the wrong direction. 4) Fix the most important problems first. That way you will quickly converge on a version which is usable, although it may not be perfect. 5) As soon as the product is usable, use it! Avoid the temptation to make it perfect. It never will be. hp |