On Tue, 11 Sep 2007 19:59:44 +0100, "JJ" <stackoverflow@[EMAIL PROTECTED]
>
wrote:
>May I ask if the software you speak of is maintained by yourself
>alone, or do you have a number of programmers for that?
>If you should die unexpectedly and your customer needs continued
>maintenance, have you provided for that in the contracts?
I provide software for different uses:
1) To use myself to perform a service contract, ie. harbour
pre-construction survey. For this, mtce is not an issue - if I die it
is not likely that I will be called upon to perform any more
services.
2) To perform a specific, defined task, with no expectation there
will ever be any mtce requirement, ie. a program to run a special
purpose, one-off 5-axis milling machine. The job is defined, the
machine is built, it performs a specific check-out test that covers
everything the customer wants to do, and it is signed off. I usually
perform a long production run myself on such systems, say a months
worth of full-time machining, getting paid operator's rates, to do a
"burn-in" test.
Customers for these machines have a life cycle in mind, and I
have never failed to have the software perform 100% to the spec.
during a life cycle, with the exception of the incident related below.
I did have one customer ask me if I could reconfigure one
machine, after about 6 years of operation, to add functions for
automatic loading/unloading of a milling machine doing cuts on some
oil well casing pipe, which I did. If I were dead, he wouldn't have
asked.
>What I am trying to imagine is whether your style of software with
>"many goto's" is maintainable by others, and if your customer(s)
>are aware of it's style and how many programmers are available
>in your place.
If you are interested, I'll relate an anecdote about this.
I once had a minor bug in a navigation system that was at sea working,
when I got an email from the very experienced survey technician who
had been involved in the original spec. and installation and testing
of the system. He said he knew a little Basic, and had some downtime
while they repaired the ROV, and he wanted to have a look at the
program to while away a day or 2 till they got back to work, and maybe
fix the irritation in the display.
As background I will explain briefly what the application was. I had
software running on an old DOS system to do real-time dynamic vessel
postioning with a Kongsberg DSP system. What it did was take exact
positions from GPS and make up the required control data stream to
simulate positioning data from the even older Artemis (radio range &
bearing) positioning system the Kongsberg was originally designed to
work with. Nobody operated with Artemis any longer.
Kongsberg wanted to sell the customer a new $350,000 DP system - I
sold them a $5,000 program created and installed over a long weekend
which they ran on an old PC/AT. Their immediate savings was $345,000
plus the 6-month lead time on purchase and installation of a new
system.
What the technician was requesting was my permission and advice to
mess with the source, and he wanted to make sure anything he did was
recoverable should he screw up, which of course it was.
The bug was a minus sign missing on a northing to correct the display
when working south of the equator.
I gave him the instructions for the bug fix and for running the
"recover from somebody screwing with the source" batch file. Then I
never heard back from him.
Meeting up with him several months later on shore, he told me how
impressed he was with the way Basic programming had progressed from
when he fisrt learned it years before, and how easy it now was to read
through the code, understand what was going on, and confidently make
his changes.
He specifically commented on my use of long, meaningful variable names
and labels, my "paragraphs of comments" to explain the tricky areas,
and my lack of comlex nested conditional structures that usually made
other code he had reviewed very difficult to follow.
Of course he was praising "my style" - not the so-called
"professional" style espoused by some of the inflated egos involved in
this discussion.
This guy didn't actually pay the bills for that customer, but he was
the main feedback directly to the guy that did, so what do you think
the answer would be from them should you ask for their opinion about
my work?
All of my systems that are actually sold to others (many I just use
myself on service contracts) are real time black box solutions to an
industrial or marine control problem. They are contracted to do a
job, and they are proven to do it. I mention the incident above
because it was just about the only time I can remember that a software
change was required in one of my systems due to programmer error.
So, you may be able to understand what I mean when I say I don't
really give a **** what anyone here might say about my programming
style. I know what works for me and my customers, I have no interest
whatsoever in spending more time making a software situation "more
complex", just because some asshole instructor in Europe 50 years ago
thought it might make software easier to manage - hahaha - if a
particularly easy-to-follow and maintainable way of writing code were
taken away from a given software development tool, just because he
thought some ill-informed or poorly-taught students were misusing it.
(Holy Jesus, I've caught the Judson virus with that sentence!).
I spent the first 10 years of my career writing new software and
maintaining old software written by others, mostly in Cobol and PL/1.
I know what makes a program easy to develop, test and debug, maintain
and modify. It is NOT multiply-nested conditional logic statements
that leave no space for meaningful lables and discouraged long
comments.
I'll stick with my style, and thanks for your interest.
|
