Spec Wars?


"Wait a minute, Roscoe," I jumped in. "I've got a little problem with your desire to pin down exactly what it is that will be delivered. Walker Royce has told me over and over again that trying to achieve too much precision early in a project is a big waste of time. For instance, insisting on extremely precise delivery conditions just leads to lots of arguing about the specs."

"Actually," replied Roscoe, "I agree with Walker. Spending lots of time on the details of what you'll deliver is like lawyers arguing about the commas in their contracts. We want to avoid that at all costs. Otherwise, nothing will ever get done, and we will spend way too much time generating useless documents.

"But there is a real problem that does need to be addressed. Here's an example. All too often, an engineer or a programmer commits to deliver a piece of code by a week from Friday, for inclusion in a larger project build. On that date the bits arrive, but the code is buggy. It takes another week to get that settled. Then you discover that when the array used in his calculation goes from 100 elements to 1,000, the algorithm takes 100 times as long to complete. So it takes another few weeks to fix that. By now all tasks that depended on that code are queued up and waiting."

Roscoe was warming to the task. He continued.

"The problem here is that the fellows never really agreed on what was to be delivered on that Friday. The programmer thought it was a piece of code. The manager wanted thoroughly debugged code that had good performance characteristics over a reasonable range of input conditions. Clearly, they didn't agree on what was to be delivered. The programmer will argue that he met his commitment by delivering the code; he will use the loophole that he didn't promise that all the bugs would be flushed out and fixed. But once you start down that slippery slope you are dead, because now you're arguing about how big a bug might 'reasonably' escape testing (if he did any testing at all, by the way). And the programmer will also argue that performance was never discussed, although his use of a quadratic algorithm[8] violates all our notions of competency and professional behavior."

[8] The input array went from 100 elements to 1,000, or a factor of 10 larger; processing time went up by 100, which is 10 squared, so we say that the algorithm has quadratic characteristics. Quadratic algorithms are easy to program, but fatal to any program to be employed seriously, as we can see. We'd like algorithms to be linear with respect to their input, if possible. The competent programmer identifies quadratic (or worse) algorithms and replaces them, most often with algorithms that are at worst n log(n), which means they go as linear times the logarithm of linear. Sometimes that's the best you can do.

Who had educated Roscoe on quadratic algorithms, I wondered?

"Now I am not saying that to fix this problem requires a detailed spec, down to exact performance numbers. But just like the oil field guy who reasonably expects his tubulars to get to Notrees without being twisted like a pretzel, the software project manager should reasonably expect that when he gets a piece of code, it's not just half-baked. Especially when the programmer knows it's going into a project build, where it will be used by other people.

"That's what I'm trying to get at," Roscoe said, leaning back in his chair.




The Software Development Edge(c) Essays on Managing Successful Projects
The Software Development Edge(c) Essays on Managing Successful Projects
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 269

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net