I believe the relative ease—not to mention the lack of tangible cost—of software updates has created a cultural laziness within the software engineering community. Moreover, because more and more of the hardware that we create is monitored and controlled by software, that cultural laziness is now creeping into hardware engineering—like building airliners. Less thought is now given to getting a design correct and simple up front because it’s so easy to fix what you didn’t get right later.
Every time a software update gets pushed to my Tesla, to the Garmin flight computers in my Cessna, to my Nest thermostat, and to the TVs in my house, I’m reminded that none of those things were complete when they left the factory—because their builders realized they didn’t have to be complete. The job could be done at any time in the future with a software update.
As a retired software developer I'm very aware that more and more of life is controlled by software. Unfortunately, some of what is software controlled is also life critical (e.g. airplanes). To design a bridge you need an Engineering degree, a PE certification, etc. To design software, there's no similar set of requirements. In addition, the "triple all your calculations and nothing will ever break" thinking of civil engineering has no counterpart in software engineering. One errant line of code can "crash" the entire system.
It's a serious problem deserving of immediate attention. As the article points out, money may be in the way at times.
The abysmal state of software quality,, in my opinion, primarily has to do with three things:
1) A general acceptance, in the software dev and user communities, of bugs. People have been conditioned to expect that software doesn’t work correctly all the time. The make allowances for, and accept, that “well, THAT feature is obviously broken.” A lot of this inadvertent training comes from the web, where web based apps as frequently buggy in one or more browsers.
2) Slavish adherence to agile processes, which are often poorly understood and very badly managed. My antipathy toward agile for the type of software that I write professionally (operating systems) is well documented. For projects where agile is used, it is most often run by people who are clueless as to how it’s supposed to really work, and mostly serves as a DISincentive to carefully design, test, and perfect your code. If I had a dollar for every time I’ve head some idiot say “Just get something working and we’ll fix it in the next sprint” I’d own a PGXL today. Shipping software that’s not fully cooked is the definition of agile. When you couple this with the new trend of flighting releases and “testing in production” you get a whole culture based being proud to ship software that doesn’t really work.
3) A lack of value, or even understanding, of software architecture and design. I could write a whole article on this. It dovetails with the introduction of agile, also. With the push to “just get something working” nobody values, and few people understand, defining an overall architecture for a system. There’s little architecture done these days. Design is not architecture.
So... it’s not laziness. It’s worse than laziness. It’s failure of the underlying systems of how most software is written. It’s conflating “I through some crap together and it seems to work pretty well” with “I designed and implemented a solution.”
Perhaps, I am a bit too old to add to this discussion, but what I see as part of the problem is the lack of connection between the person doing the programming and the end user of that program. My first job was working in a postdoctoral research laboratory. There was a mixture of EEs, physicists, and other scientific professionals. One of the major problems was handling all of the data being generated in the experiments. I remember seeing high-speed printers turning out foot tall piles of paper that were nothing more than numbers. Some members of a team would want to look for patterns in the printouts. Some members would want to test theoretical equations against the printouts and so on. If you wrote a program to test a theoretical equation against the data set and it didn't work, you had to look that researcher in the eye. It was tough enough to see the disappointment when a theoretical equation didn't work out that you didn't want your work to make even a bigger mess of things. A programmer today never gets to see the end-users disappointment when their programming efforts fail or go awry.
Footnote: I was working there in the
1970s. My biggest hit in programming was one that allowed the user to
change the strategies in card counting to maximize their odds playing
blackjack. I was surprised by how many scientists are gamblers.
The 737 Max Series Aircraft are NOT Tesla Autos, Nest thermostats, Garmin or Flex Radios. The problem here is a CURRENT design of 737's the 700, 800 and 900's were confronted with AIRBUS' competing product that was smoking the Boeing in fuel economy. When you're burning thousands of pounds in fuel during a flight, Better Gas Mileage is Important at keeping an airline's cost per seat mile as low as possible.
Well a NEW engine, an even higher bypass turbo fan was developed and to bolt a pair of those units on to the 700-800-900 airframes Boeing needed to extend the landing gear, and shove the engines closer to the wing and further forward.
The end result is an aircraft that additional thrust causes the NOSE of the aircraft to rise increasing the angle of attack... They had to implement this MCAS system to allow the aircraft to FEEL LIKE the previous versions of the aircraft so pilots could move between them without feeling a change.
The airlines just need to implement differences training between the New Generation 700 etc and the Max... The system allows the Airframe to handle LIKE the previous airplanes. Here's the wording.
****The Maneuvering Characteristics Augmentation System (MCAS) is a flight control law managed by the flight control computer (FCC) and introduced on the 737 MAX to help it handle like a 737 Next Generation (NG), particularly at slow speeds and high angles of attack (AOA).****
The problem is the dual Angle of Attack Sensors were optional even with the MCAS (they made them mandatory now... but the pilots still need training if an AOA sensor fails and how to diagnose that.) Unfortunately there were a couple aircraft that fell out of the sky due to the pilots not receiving enough simulator and diagnostics training along the way and had no clue what was happening.
I watched an in cockpit simulation of the second crash with discussion while it was happening and I was unable to follow why the A/C pitched sharply down and everybody died...
I stepped out of an airline pilot's seat in 1993 and admit being rusty however I'd never felt like I was out of control for no reason in perfect flying conditions before, I was able to follow their flight right up to the point the pilots started freaking out. Of course I couldn't feel the plane fighting at the controls. DUH?
This IS nor WAS ever a software issue... This in both cases had been an AOA Sensor failure issue. Even on the twin sensor systems, the pilots NEED to be trained at How to diagnose which sensor has failed and which is correct for them to properly fly the plane. Do some of that Pilot S*** Mav... I do believe these pilots didn't get enough training to safely fly these birds.
These ARE NOT software controlled airplanes... So the problem isn't bad software the problem is/was inadequate training. Boeing is NOW adding lines of code to anticipate undertrained pilots???
What about SDR? Advances and revisions in SDR software if an issue was found and a fix was designed for that issue that's one thing... Adding additional features that's different, Repairing an issue with the original hardware? Doubtful.
Even with an SDR radio $$$$ must be spent in the original design to build components in the Signal Path like LO's, and A/D conversion devices at the absolute leading edge of technology... and then designing software that anticipates every possible feature for each of those devices to please the customers When You're talking new technology it would take Johnny Carson as Carnac the Magnificent to foresee every possible vision the customer might come up with or future need so the processor can deliver at the design onset.
Be pleased they keep updating our software.... My windows 10 Pro x64 still sees a blue screen every once in a while... Microsoft KNOWS there's thousands of potential issues running around in these computers... NOBODY is smart enough to design a software O/S that complex with the first revision.
- 5087 Conversations
- 1544 Followers
- 3002 Conversations
- 621 Followers
- 3532 Conversations
- 903 Followers
- 949 Conversations
- 392 Followers
- 854 Conversations
- 148 Followers
- 309 Conversations
- 79 Followers
- 376 Conversations
- 141 Followers
- 452 Conversations
- 158 Followers
- 416 Conversations
- 144 Followers
- 374 Conversations
- 137 Followers
- 2909 Conversations
- 829 Followers
- 454 Conversations
- 159 Followers
- 926 Conversations
- 247 Followers
- 1193 Conversations
- 293 Followers
- 414 Conversations
- 127 Followers
- 946 Conversations
- 142 Followers
- 861 Conversations
- 119 Followers
- 1023 Conversations
- 148 Followers
- 1019 Conversations
- 139 Followers
- 146 Conversations
- 58 Followers
- 93 Conversations
- 29 Followers