??? 08/01/08 17:24 Read: times |
#157229 - It's a tradeoff Responding to: ???'s previous message |
Erik Malund said:
...some of Richards "it must ALL be documented before ..." are very important for consulting, but in a regular job, the reality is, you should be happy if the spec you work from is 80% right. Richard is adamant "do what the boss tell you to do" and I have, outside consulting, never experienced a full spec from "when the boss told us to" start. That's probably true ... sadly ... and it's probably the reason many people in senior positions in larger corporations still see the "software guys" as a pool of t-shirt-wearing, Jolt-drinking, sneaker-wearing, pot-smoking chimpanzees rather than as engineers. Now, I won't debate the merits of what one wears, drinks, or smokes, but it does point out that working from incomplete spec's is what has defined software engineering as an oxymoron for decades. It's true that it's difficult to get firm spec's from anyone who wants something done. I deal with that all the time. It's also true that one can't complete a job, or define the nebulous notion that "it works" until someone specifies a firm, verifiable, and testable definition. If you're building one of those ATMEL-targeted "kitchen table" programmers, where it doesn't matter if the thing works more than once in ten attempts, then maybe one can be a bit forgiving in the need for formal requirements documentation. After all, nobody wants to admit that "works once in a while" is good enough, though it seems to satisfy ATMEL users well enough. If you want to design something, however, you have to start with a specification of the problem it is supposed to address. If you can't do that, you can't design a solution to the problem, because you don't know what the problem is, hence, you don't know when it has been solved. If I had to wait until "it works" is satisfied before being paid for my efforts, I'd be a lot thinner. That's a moving target! If it has to meet these conditions under these circumstances, this many times out of this number of repetitions, then I know what I have to do. When a client approaches me with a poorly specified task, I first get him to pay for the development of a firm, precise, and agreed-upon specification before work begins. He'll cry and complain, but as his deadline approaches, he'll see the value in it, and we'll have a set of spec's that ensures he knows, in advance, what he'll get, and I know, in advance, when the job is done, and when I get my money.m If somebody else will let him get away with looser specifications, well, then somebody else can do that piece of work. My clients know I won't willingly clean up somebody else's mess without charging a significant premium. If I were his employee, I'd not worry about that ... after all he's paying for my time, so it's his to waste. RE |