are programmers "failures"?

[Don Shepherd]

(03-25-2019 03:42 PM)Eddie W. Shore Wrote:  At first you don't succeed, try and try and try and try again

Eddie, I have found the following strategy to be helpful when I write an RPN program for my HP-65 or HP-12c or a Solver equation for my HP-17b. After I enter the program into the calculator and it compiles (for the 17b), I try to run it. If I don't get the results I expected, the first thing I do is to compare what is in program memory with my code as written on paper. That frequently solves the problem, because some of these old calculators (especially my 65) seem to add a keystroke now and then and you aren't aware of it. Only after I verify the stored program is the same as my paper copy, do I start re-examining my logic to find the error.

[Dave Britten]

As a programmer, I can say that I always get a little nervous when something compiles and appears to run correctly on the first try. Especially if I've spent more than 30 minutes writing it.

[Pekis]

... and a bug always appears when you show a demo to someone else ...

- Check it out !
- Oh, shit ...

[Brad Barton]

The traits that ALL truly successful people possess is the ability to absorb repeated failure, learn from it and, most importantly, TRY AGAIN! Edison, Bell, Wozniak, etc., are only a few examples of people who got knocked down over and over, but refused to accept defeat. By this definition, all programmers are truly successful people.

[KeithB]

I call my programming methodology "Stepwise refinement by Compiler error."

[Leviset]

After a lifetime in IT, starting off programming an HP-97 commercially in 1979 then various Mainframes/Minis (Sperry Univac, IBM System 38, AS/400) and being fortunate enough to be in the vanguard of the PC Revolution (8088/8086, CP/M, MSDOS, Windows etc.) from 1981 and using COBOL. ASM and various high level (but slow) database packages like dBase II/III, Open Access, DataPerfect mainly as a freelance contractor but some permanent work as well, I never felt a ‘failure’ but I was ‘challenged’ many times. My son has followed on in my IT footsteps, he is now a highly paid COGNOS TM1 expert - but I doubt if he or other young IT folk will ever get the chance to do something completely new. Even back in the 70/80s my main work would involve converting old code to run on newer hardware, bolt ons to existing software, upgrades - I can only think of 2 major commercial projects that I would consider ‘new’ at the time. Nowadays I see the same projects jazzed up and running on the web, in the cloud, on a mobile. The real ‘Genius’ has always been the one who can ‘think up’ a new application (like Word Processing, Spreadsheets, Database software etc.) for the first time, bit like trying to think up a new board game (think Monopoly) for the first time. It doesn’t matter if you can’t program it, it’s the new concept that is very hard to come up with and there’s always an army of contractors out there (like I was) who’ll do the ‘clever’ programming stuff for peanuts compared to the ‘entrepreneur?’ Who’s going to earn big bucks. Take Gates - what average 19 year old student had $79,000 in loose change so he could buy the original DOS sourcecode from a ‘friend’? I moved to System Testing and then Computer Operations (where you are called a ‘failed’ programmer!) for the latter part of my career. Eventually you find there may be a small interesting algorithm you need to come up with in the middle of the ‘new’ software you’ve been asked to write, but 99% of your ‘new’ program will have been done before and you’ll cut and paste it in from libraries or other programs/sub-routines and rarely get the chance to ‘add’ something new to the library. Eventually I found the challenge of managing failures in real time, time critical applications caused by poor/hurried/untested programmer’s Code much more interesting even though I was a ‘failed’ programmer according to the system development teams - but nobody like a Poacher turned Gamekeeper who knows all the Poacher’s tricks!
Just thought I’d liven the discussion up a bit.

[Don Shepherd]

(03-28-2019 10:37 AM)Leviset Wrote:  After a lifetime in IT, starting off programming an HP-97 commercially in 1979 then various Mainframes/Minis (Sperry Univac, IBM System 38, AS/400) and being fortunate enough to be in the vanguard of the PC Revolution (8088/8086, CP/M, MSDOS, Windows etc.) from 1981 and using COBOL. ASM and various high level (but slow) database packages like dBase II/III, Open Access, DataPerfect mainly as a freelance contractor but some permanent work as well, I never felt a ‘failure’ but I was ‘challenged’ many times. My son has followed on in my IT footsteps, he is now a highly paid COGNOS TM1 expert - but I doubt if he or other young IT folk will ever get the chance to do something completely new. Even back in the 70/80s my main work would involve converting old code to run on newer hardware, bolt ons to existing software, upgrades - I can only think of 2 major commercial projects that I would consider ‘new’ at the time. Nowadays I see the same projects jazzed up and running on the web, in the cloud, on a mobile. The real ‘Genius’ has always been the one who can ‘think up’ a new application (like Word Processing, Spreadsheets, Database software etc.) for the first time, bit like trying to think up a new board game (think Monopoly) for the first time. It doesn’t matter if you can’t program it, it’s the new concept that is very hard to come up with and there’s always an army of contractors out there (like I was) who’ll do the ‘clever’ programming stuff for peanuts compared to the ‘entrepreneur?’ Who’s going to earn big bucks. Take Gates - what average 19 year old student had $79,000 in loose change so he could buy the original DOS sourcecode from a ‘friend’? I moved to System Testing and then Computer Operations (where you are called a ‘failed’ programmer!) for the latter part of my career. Eventually you find there may be a small interesting algorithm you need to come up with in the middle of the ‘new’ software you’ve been asked to write, but 99% of your ‘new’ program will have been done before and you’ll cut and paste it in from libraries or other programs/sub-routines and rarely get the chance to ‘add’ something new to the library. Eventually I found the challenge of managing failures in real time, time critical applications caused by poor/hurried/untested programmer’s Code much more interesting even though I was a ‘failed’ programmer according to the system development teams - but nobody like a Poacher turned Gamekeeper who knows all the Poacher’s tricks!
Just thought I’d liven the discussion up a bit.

thanks Denny, what an interesting career.

That PC revolution was really something. I remember attending a Washington Apple Pi meeting shortly after the Macintosh came out in 1984. They had a rep from OverVue corporation who had just released what was probably the first "data base manager" for the Mac. It even had a rather sophisticated macro language enabling you to automate many DB functions. The rep had come with about a dozen copies of the DB software for sale and people swarmed his table after the presentation, grabbing one to buy. I think the rep was worried that some folks would take one and not pay for it (about $99 as best as I can recall), but people just didn't do that in those days and he sold all twelve and could have sold probably a hundred!

I was treasurer at my church in those days and I used Excel VBS on the Mac to track the accounts and transactions and generate the financial summary report for the quarterly business meetings. It was much more fun and satisfying to do it that way versus buy something like Quicken.

[pier4r]

(03-24-2019 10:50 PM)Thomas Okken Wrote:  witness the fact that every Agile apologist ever is always going on about how people don't understand it and are doing it wrong

This is a good point.
If the idea you think that works is never properly applied, then the idea belongs to the "fantasies" category, rather than reality.

Trying to force a vague idea on reality realizing that it doesn't work and still lamenting that it can be done, is denial.

The base idea may be good, but has to be reworked to be applied in reality. Until then it has no practical value.

[Maximilian Hohmann]

Hello!

My personal experience:

When programming was "difficult" (e.g. in my early days of programming calculators and when using punch cards to write programs on mainframes) the error rate was exceptionally low. One would carefully write down - on paper - every instruction and test it "dry" before punching it onto a card (or typing it into the calculator). Then put the stack of cards into the reader and paitiently wait a couple of hours for the results. Failure was not an option because it would cost another work day.

Later, when CRT terminals and desktop computers became available to me, I did what most people did and adopted a "shirtsleeve" approach to programming: Just type into the terminal what comes into your mind, let the compiler be your spell checker and run the program. If the result looks halfway decent, submit the code to the project manager and let the customer do the final debugging ;-) Never before and after have I been more productive in my life. Some of the code which I wrote that way was used to design the largest airliner in the world (which unfortunately, due to lack of demand, will cease production very soon).

Then came ISO 9000 (or Agile or whatever else it may be called elsewhere) which meant that for every hour of writing code one was required to spend nine hours doing paperwork, documentation, test cases, testing, acceptance testing, kick.-off meetings, other meetings, ... you name it. Took the fun and productivity out of the job completely. And the results? No A380 has come to grief yet, but two B737 Max airliner crashes have taken more than 300 lives recently despite their software being developed under those stringent rules.

Personally I have pulled the plug and stopped programming for renumeration. I expect satisfaction from my work and that was no longer possible for me. Now I fly our corporate jet (which of course is very much regulated as well but not as much as producing technical software) and enjoy the view.

Regards
Max

[pier4r]

(03-28-2019 07:03 PM)Maximilian Hohmann Wrote:  for every hour of writing code one was required to spend nine hours doing paperwork, documentation, test cases, testing, acceptance testing, kick.-off meetings, other meetings, ... you name it.

If there would be documentation, test cases, testing and so, it would be gold! In most cases, far away from constructing aircrafts (that are still something very fragile), there is nothing of the sort.

Agile in theory should be a collection fo cycles with a reflection in each cycle. What we did good? What was wrong? What should be improved?

There is none of it in most companies.
Testing? no.
Reviews? no.
Adjusting the plan? no.
Documentation? Haha, good joke.

etc...

If there would be what you mentioned, it would be much better. Tedious maybe, but better.

[badaze]

I consider myself as a good programmer. Nonetheless I’m still suprised when a program works at the very first compilation. So surprised that I spend more time on testing than usual.

[Dan]

(03-28-2019 07:03 PM)Maximilian Hohmann Wrote:  Two B737 Max airliner crashes have taken more than 300 lives recently despite their software being developed under those stringent rules.

Apparently erroneous angle of attack readings from the nose sensor caused the computer system to overcompensate, throwing the planes into a dive.

There are claims that the Ethiopian pilots fought the computer system for the entirety of the six-minute flight, but weren't able to pull the nose up.

Boeing engineers said pilots didn't know how to override the system, and two critical safety features were sold as optional extras!

WTF!!

[mfleming]

(04-05-2019 07:12 AM)Dan Wrote:  There are claims that the Ethiopian pilots fought the computer system for the entirety of the six-minute flight, but weren't able to pull the nose up.

Watched an "Air Disasters" episode last night about a crash of an Air China A300 flight at Narita airport in Japan. The pilot accidentally pressed the Go Around switch on the throttles while descending for a landing. The switch causes the flight control computer to increase power and raise the nose. Unaware of what the F/C was doing the pilot initially fought to push the nose down to complete the landing, then decided to do a manual go-around by pushing the throttles forward and pulling the nose up. The plane pitched steeply up and again the pilot fought the controls to bring the nose back down. At around 50 degrees angle of attack, the aircraft stalled and then pancaked off the end of the runway. Seven passengers actually survived.

The go-around indicator was a small light in a sea of displays, the go-around mode could only be cancelled by switching to another mode and, unlike other aircraft the two pilots were familiar with, pushing the stick hard forward did NOT disengage the autopilot on the A300 at the time.

Small things, small things...

NB. Airbus had issued an upgrade notice that would have cancelled go-around mode if the controls were pushed hard forward, but because it was not marked safety critical, the upgrade was scheduled for the next major maintenance period. None of the six A300s in the carrier fleet had received the upgrade at the time of the crash.

[Albert Chan]

Real reason of 737 Max Crashes




And, a counter-argument of MCAS software failure. I guess time will tell ...

[John Keith]

And a very thorough technical overview here.

[Leviset]

Having not written a commercial program since 1991, I did for a few short years head up a System Testing Unit for a large Worldwide Bank. The software was a vanilla suite called Base24 which ran on the new non-stop architecture of Tandem minis.
It had been modified to match the UK Banking Systems and the introduction of Reciprocity between all the UK Banks & Building Societies. I can assure everyone that this was tested to death as software that affects Monetary transactions has always been more important than a few planes falling out of the Sky!
However I seem to remember from my ITIL/ISEB days then there was an algorithm back then (and is still?) that stated that it was not ‘Cost Justified’ to test software to more than 83% of the total 100% possible. I’m pretty sure large Software Houses like Microsoft & IBM played to this rule with customers not knowing that it was ‘cheaper’ to let end users find the remaining ‘bugs’ (if any) and then fix them later with a so called ‘update’ release under the guises of an ‘enhancement release’.
I also remember in the 90s discussions about the Air Traffic Control Systems at Heathrow & Gatwick which used software & hardware in excess of 20 years old and that nobody wanted to take on replacing those systems (I seem to remember that the software ran on either Sperry/Univac or Unisys Mainframes?).
I know we have some pilots on this Forum but do we have anyone who has worked on replacing vintage ATC software & hardware - I’m assuming by now the software/hardware has been updated and no longer running on valves & Cobol?
How on Earth do you test a critical system like that? We used TPNS to simulate millions of ATM transactions taking place along with some real different models of actual ATMs being used non-stop over a period of 72 hours simulating the known peak periods, like the 2 weeks prior to Christmas.
I’m again assuming (because I actually don’t know) that ATC testing used Flight Simulation Software along with some real planes with test pilots that mimicked actual peak periods at major world airports? I certainly hope that they ignored the 83% testing rule and got as close as possible to the unachievable100% as I do actually believe passenger safety supersedes any money systems in terms of priority BUT I think there may be Financial Directors and/or Bean Counters of large Corporations that would think the opposite.
I have to agree on Agile - I have a friend who is an Agile Consultant (is that an Oxymoron?) Contractor who lives and breathes the stuff BUT I’ve always been a bit sceptical of these ‘fly by night’ so called ‘improvements’ to Project Managent especially when it involves phrases like ‘Blue Sky Thinking, Helicopter View(s), circle back, reach out and Morning Scrums. Any Processes or Management Techniques that would have required me to “stick my head up other colleagues bottoms” would have had me racing off to find a new contract!

[Don Shepherd]

(04-30-2019 10:08 PM)Leviset Wrote:  I also remember in the 90s discussions about the Air Traffic Control Systems at Heathrow & Gatwick which used software & hardware in excess of 20 years old and that nobody wanted to take on replacing those systems (I seem to remember that the software ran on either Sperry/Univac or Unisys Mainframes?).
I know we have some pilots on this Forum but do we have anyone who has worked on replacing vintage ATC software & hardware - I’m assuming by now the software/hardware has been updated and no longer running on valves & Cobol?

Back in the 1990's I was a manager of a group of testers charged with testing a new air traffic control system for the US, called AAS (Advanced Automation System). This included new hardware and software. The legacy IBM 9020 hardware (based on IBM 360 mainframes) and JOVIAL software was being replaced by Ada software running on IBM RISC/6000 systems. After about 3 or 4 years of cost overruns and slipped schedules the project was cancelled. Getting Ada code to work turned out to be a tough nut to crack, but I suspect that a bigger problem was that the FAA essentially wanted a single ATC system to run in both Enroute Centers and terminal control centers, but neither the enroute people nor the terminal people wanted that because they knew that the requirements for these two types of facilities were very different. I moved onto a different project and lost track of what was happening with ATC systems but I do know that new hardware and software was eventually built and installed in both enroute and terminal facilities, and I would assume that the system is safer and more reliable today than if those legacy systems were still around.

[pier4r]

From the post about "testing", exhaustive testing of all possible real world scenarios is likely not possible. So one has to come up with significant test cases and that is not easy.

On a side note, the sentence: "software that affects Monetary transactions has always been more important than a few planes falling out of the Sky!" is as sad as it is true.

[aamiel]

I am not a programmer but I do work on replacing ATC systems.
With those, there are serious testing requirements (here) but the CAA themselves say we don't really know what testing we need.
The main difference with financial software is that there are many layers of protection, the computer program, the controller, the plane, the pilot, the size of the sky...
There are issues in ATC software that crop up regularly (every few years we shut down the UK sky), that are know about, etc... my job is to minimise them but I can tell you I am very busy so it is not perfect and we live with it.