In
spinoza1111wrote:
Without troubling my memory too much, I can personally recall eight
different large projects on six different sites (i.e. for six
different companies), where we developed using Microsoft C but where
the target platform was a non-Microsoft platform (sometimes Unix,
sometimes MVS/OS390, sometimes set-top boxes).
Generalizing from failure, I see. There were probably thousands of
bugs in what you did, but based on your behavior in this ng, you
doubtless found other people to blame.
It was precisely because we needed portability that C was chosen.
Did you also design the rudder on the Titanic?
I say this because you don't seem to know what portability is. News
flash. It's not the availability of a compiler. It's whether the code
runs correctly when written naturally on multiple platforms. You
yourself have pointed out that a large amount of specialized knowledge
is involved in writing truly portable C and it would be best for you
to GET OUT OF THIS DISCUSSION and write a book or teach classes in
what you honestly know...you probably won't do so because you prefer
being a bully.
If Java or .Net was not available at the time you worked on this
project on some of the platforms, it probably would have made more
sense for you to port, not C code, but Java or .Net to the platforms
needing one of those tools, engaging a contractor as necessary.
Alternatively you should have used Cobol which despite its flaws is
far more portable than C, and more suitable to the financial
environment in which you worked.
You were in fact profoundly irresponsible with what Eric Hobsbawm
calls "the destructiveness of the lower middle class" because even if
everything worked, you left code that it easily changed, intentionally
or unintentionally, to something completely non-portable with
incorrect behavior (starting with memory leaks) that is never
detected.
You designed, I believe, the rudder on the Titanic and then you took
the money and left Belfast for London.
It's called "writing the code", and - where portability matters -
portability violations are considered bugs at code review.
I don't think you're qualified to attend a code review.
One of my clients had a half-million-line set-top box Web browser, of
which 495,000 lines were written in ISO C, and only 5,000 lines,
carefully isolated into separate modules, had to be rewritten for
each new platform. (I take no credit for that, by the way - when I
joined the project, the basic code had already been there for quite a
while, and we were just working on new features; my mentioning it is
intended not for false kudos but as a data point on portability.)
There was no need to review the 495,000 lines for each new platform -
we just ran the tests after each port and after each feature we
added.
And left a mess for the next fool in the same way as banks sold
tranches of toxic loans.
You don't seem to be aware that testing can reveal the presence of
bugs and not their absence.
These large software systems cannot, owing to their size, be properly
evaluated by anyone, least of all their developers, especially when
one of their leads proves here to be dishonest and incapable of
working in a group effort without disruption.
I say there was a need to review the 495000 lines and you didn't do
your job. At a minimum, did you
(1) Fix all warnings issued by compilers when the code was ported to a
new platform?
(2) Set warning levels sufficiently high (to "lint" levels), or
(3) Use a lint-like tool to evaluate portability?
Or did you just watch the stuff run with your mouth open and declare
victory as long as nothing crashed?
Most auditing firms would find you erred IF you made the decision to
use C after circa 2000 for by that time two tools (Java and .Net) were
available for write-once run-anywhere, and not to use them in the
financial context, using instead a language with known issues such as
C, was bad practice.
If you worked for Northern Rock then as an employee under UK law you
are probably indemnified because under UK and American law, it is a
legal axiom that no matter how incompetent an employee might be, he's
not to blame for decisions that are made or signed-off on by
management. Nonetheless it appears to me that insofar as you worked in
"banks and insurance companies" your decisions helped to create a
mess, and I wouldn't pat myself on the back I were you.