Bill Hinshaw is not a typical 75-year-old. He divides his time between his famil…
If I ever get tired of working in the aerospace industry, looks like there is plenty of need for old COBOL programmers….
Software Engineering
There are 42 posts filed in Software Engineering (this is page 3 of 5).
737-MAX software update still in progress, Collins Aerospace/UTC is involved
From recent reporting, the FAA is still several weeks away from approving the MCAS software changes relating to the Lionair and Ethopian Airlines crashes. In the industry media I read, I had not seen anything whether this was software created by Boeing or by one of its suppliers. This morning, I decided to do a search, and quickly found that it was my company (Collins Aerospace) involved in MCAS software development, and that Collins Aerospace supplies the computer that runs the software. Hoo boy!
- Washington Post: Boeing’s 737 Max design contains fingerprints of hundreds of suppliers
- The Gazette (Cedar Rapids IA, former headquarters location of Rockwell Collins/Collins Aerospace): United Technologies is parent company of sensor maker under scrutiny for Boeing 737 Max failure
“Boeing 737 Max: What went wrong?” (BBC) contains a plot showing the angle of attack data being fed to Boeing’s MCAS software. Less than one minute into the flight, the left sensor spikes to an absurd roughly 70-degree angle of attack. Given the weight of an airliner, the abruptness of the cha…
Philip Greenspun makes it sound simple, after the damage has been done. The trick is to figure this out before there is an accident.
Read: Discussing Social Networks, Again
Amit GawandeAnother week, another discussion on the state of social networks on TWiT network. This time it took place on the latest episode of This week in Google . The discussion went on and on about how Google Plus was great. And how other social networks have ruined what made them the best in the first plac…
I think that any tool can be a social network, we should start networking with whatever we have!
Read: Java’s Forgotten Forbear
Java’s ability to run on many different kinds of computers grew out of much older software
An interesting history of an early Pascal development environment. Turbo Pascal was also an early success for PC software development.
(via Dave Winer) – I used Fortran as my first professional programming, interesting to see that there are still so many users…
How embedded software projects run into trouble
Jack Ganssle has written articles for his top ten list of how embedded software projects run into trouble. Most of this could apply to any software project! Here are the links:
- Unrealistic schedules
- Quality gets lip service
- Poor resource planning
- Writing optimistic code
- Weak managers or team leads
- Crummy analog/digital interfacing
- Bad science
- The undisciplined use of C and C++
- Jumping into coding too quickly
- Not enough resources allocated to a project
Is there something you do every day that builds an asset for you? Every single day? Something that creates another bit of intellectual property that belongs to you? Something that makes an asset yo…
When I read this, I decided to start working on the asset that is my weblog. I will strive to post something daily, even if it is only a link….
Open Design Kit: methods for doing distributed design
The debt metaphor in software development
In a new post, Ward Cunningham shares his thoughts on the “debt metaphor” in software development. One of the points he brings out is that programming can be thought of as making decisions now on the functionality of the program and deferring others to a later time (debt), with the understanding that as the program matures, refactoring can occur to make the program more efficient/better (paying back the debt).
In my experience in avionics software development, the creation of software is driven by approved requirements. As requirements change or are refined, the software is updated to be consistent with those requirements. One type of “debt” I see is when functionality is not completed on time, and gets deferred to a later software release (cost increase). Another type is when a problem is found (requirements, source code, tests, documents), but addressing the problem is deferred to a future time (the problem does not impact the functionality of the requirements, source code, or tests, or is deemed not a safety issue). This type of debt (typically called “open problem reports” (OPRs) is getting more scrutiny by aircraft certification agencies and OEMs (Bombardier, Boeing, etc.), since they see increasing numbers of OPRs as an indicator that the overall “health” of the software may not be as good as it should be, and that there should be as few OPRs as possible (in other words, fix your problems as you find them).
For myself, I prefer to fix problems when they come up. However, when you work as a member of a team, sometimes business decisions dictate otherwise….