Re: modularity... (was: Re: Looking for real world examples to explain the difference between procedural (structured?) programming and OOP)


"H. S. Lahman" <h.lahman@xxxxxxxxxxx> wrote in message
news:LAN0m.1160$NF6.178@xxxxxxxxxxxxxxxxxxxxxxx
Responding to cr88192...

usually, "correctness" is relative, and can be relaxed:
does it work in the cases I (or, the users) are likely to care
about?...
The level of reliability is one of the most important business decisions
to be made. In shops that know what they are doing it is negotiated with
business management and usually applies to all work. (Exceptions for
individual projects need to be authorized by someone higher up the food
chain than software line management.) The shop then tracks reliability
religiously and when it exceeds the SPC envelop the developers have to
figure out what went wrong in the process and fix it so it won't happen
again.


I guess it also depends a lot on the expected level of reliability for
the type of software...
for many types of app, the occasional crash is merely an inconvinience,
and so the level of effort required for QA may well be too expensive...
(it being cheaper to verify that the app more or less works as expected,
and then ship it in this form...).

after all, which is better?...
a reliable app;
an app with all the newest and fanciest features (nevermind the
occasional bug here and there...).

That's fine. My issue, though, is that it is a business decision rather
than a CS decision. All too often the developers make the decision and
line management isn't even aware that it was made.


yeah, that is bad...

I guess specific policies would need to be set, ... (as in, what are the
default courses of action, and when it is needed to call up the boss or
similar and ask...).

I would have assumed that any important decisions will have been made by the
boss and indicated to those below, such as setting a particular due date, or
indicating if it is more important that something works, ...


Back in the '70s (early '80s?) a guy named Crosby wrote a book titled
"Quality is Free" that was a best seller. That notion is a crock because
of exactly these sorts of trade-offs. But it turns out that what Crosby
was really saying was that the real costs of poor quality are so great
that they are invariably more than the cost of producing good quality, so
it always pays to produce a quality product. Back when he wrote the book
he was pretty much right because quality was abysmal. Today there are a
lot more exceptions as shops approach 5-Sigma reliability and whatnot, but
it is still largely true.


yes, ok.


Unfortunately a lot of those "real costs", such as lost market share
because of a poor quality reputation, are very hard to quantify. So the
decisions are becoming tougher. But because those costs are outside the
software realm, that is all the more reason why developers should not be
making them.


makes sense.
I had just implicitly assumed though that it would not be the developers
making these decisions...

I would have figured the natural inclination of the programmers would be to
waste all of their time away doing fiddling, fine tuning, testing, ...
resulting in the product never really getting out the door... (this then
being why the boss would set due dates, well, and also to spur the
programmers into action so that they don't use up too much time conversing
or debating or similar about relatively unimportant issues...).


"should I do it this way or that way?..."
calls up coworker, "what do you think, this way or that way?..."
several others get involved.
it soon turns into a squable over the best possible implementation strategy.
soon, the programmers decide each to do their own version, and then run
comparative benchmarks.
....

boss: "so... how is that feature comming along?...".
disturbed to find out that the feature is still not implemented, all of the
programmers are instead setting up simulations and test cases, many of which
could easily take a good portion of a week to write and test...

boss: "get it done damn it!..."


or, at least, I am well aware how addictive the repetitive
fiddle/test/consider/fiddle/test/... cycle can become... as well as the
tendency to squander away all ones' time on usenet/...

or such...



.

Relevant Pages