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

Responding to cr88192...

for those of us who do use 3GLs, coding issues are primary...
I have to disagree. One thing I learned way back when I was doing procedural development: of all the things a software engineer does, coding is the least important. [That can be extended even to 4GL environments. Actually writing down the pretty bubbles & arrows is a form of coding and it is still the least important thing the developer does.]

as I see it, the most important thing is probably "get it done" and "make it work".
<historical aside>
Back in the '70s the AT&T School of Programming came close to setting software development back by a decade because Kernighan, Plauger, et al were very influential and they institutionalized the slogan, "If it ain't broke, don't fix it." So the notion of refactoring code after it was working to make it more maintainable became anathema. It took until the '90s for the industry to realize that large applications need to be maintainable because if they aren't it won't be feasible to get them to work in the future. IOW, pay a little now or pay a lot later. Today such refactoring is not only accepted, it is mandated by the OOP-based agile processes.
</historical aside>


I guess, in a commercial setting, whatever is better is whatever saves the most time and money.

Yes. In the end software quality is a business decision, not a CS decision.

FWIW, I've always considered correctness to be a given. If the application isn't working properly, it isn't finished yet. So I usually take the correctness issue off the table when considering what is important.


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.

<yet another apocryphal anecdote>
Once upon a time we had to make an important change for a customer (i.e., the customer would be dead in the water at a cost of 5 figures per day). The change was trivial; a one-line cut&paste insertion of a function call. What could possibly go wrong? The problem was there was a time bind and to test the change required a hardware setup that would take half a day. So we made a Hallway Decision with the QA people and agreed with them that we would not test it and would rely on their acceptance tests, which they had to do anyway, to verify the change.

Naturally Murphy's Law came into play and somehow that test was not run by QA and the one line change turned out not to be cut&paste. So the Division VP got to spend half an hour on the phone with a Fortune 500 CEO getting his ass chewed.

Fortunately, by that time the shop was pretty Enlightened so the VP did not start looking for someone to fire. Instead it was viewed as a process problem. That is, the real problem was that Engineering and QA made an important decision to override the process (Engineering did not do its normal testing) that it should not have made. Given that we knew if the change was bad it would cause major problems, it wasn't our decision to make. So the fix was to make sure that sure process overrides were run past business line management. (QA, of course, did they own internal review to determine how the test got missed.)
</yet another apocryphal anecdote>


after all, if no one ever sees a given bug or deficiency, what is the point of being concerned that it exists?...

The requirements are defined for a reason. It is not up to software development to decide what the customer cares about.


similar goes for rare edge cases, which can usually either be ignored, or a special case can be added such that it "breaks nicely"...

<yet another apocryphal anecdote>
We had a complex program that solved an np-Complete problem for hardware layout. Deep in the bowels of the computation there was a calculation involving the difference in {X, Y} location of two pins that needed to be connected in three dimensions. The accuracy of the location was double precision. The computation was used to optimize the wire length for the connections of thousands of pins and part of that computation involved dividing the difference in distance into another number.

We eventually got a zero-divide when the hardware coincidentally lined up with two pins in exactly the same {X, Y} location to double precision accuracy. It took nearly ten years for one of 600 systems running 24x7 to encounter that edge case. The total cost to the taxpayers for upgrading those systems with a fix was probably well into 8 figures.
<yet another apocryphal anecdote>



--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman
H.lahman@xxxxxxxxxxx
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
.

Relevant Pages

  • Calling excellent engineers!
    ... Hardware Testing Engineer - Mountain View ... Assist in the design, bring-up and testing of new hardware ... BA/BS degree in Electrical Engineering or related disciplines. ... Minimum of 8 years experience in electronics packaging or ...
    (sci.electronics.equipment)
  • Communications Systems Engineer - Cincinnati OH
    ... Establish and allocate specific performance and design requirements for ... engineering interfaces. ... System functions include customer ... Experience with radio communications systems is necessary, ...
    (comp.dsp)
  • Re: Strong typing vs Strong Testing
    ... >There is an art to all human endeavors that require skill, including math, ... >such (don't have a handy definition for that sense of art). ... >hardware design/construction, lies clearly in the realm of engineering. ... Hardware engineering has physics. ...
    (comp.object)
  • Re: Royalties for Engineering Services
    ... I get the impression that you are treating this percentage deal as a better, or at least an equally good, method of arranging for payment for your services. ... a customer would never agree to the percentage idea unless that customer is financially desparate and cannot pay your fees at the time the fees are earned. ... The reason that the percentage arrangement is not attractive to the non-desperate customer is that the percentage could far exceed the value of the engineering services. ...
    (misc.legal)
  • Re: Royalties for Engineering Services
    ... could pool resources to insure payment. ... a customer would never agree to the ... pay your fees at the time the fees are earned. ... percentage could far exceed the value of the engineering services. ...
    (misc.legal)
Loading