View previous topic | View next topic

Education Rant

Page 4 of 6
Goto page Previous  1, 2, 3, 4, 5, 6  Next

crissdee
1337511.  Wed Nov 27, 2019 12:39 pm Reply with quote

Is it actually true that tiny transcription errors can send satellites off to Betelgeuse and aeroplanes down into the Marianas Trench? It seems entirely feasible to me, but then I know less of coding than I do of maths, so that's not much to go on.

 
PDR
1337521.  Wed Nov 27, 2019 2:27 pm Reply with quote

In most cases it's due to mixed units (typically imperial and metric) or "type-casting", which means using a piece of data stored in one format (eg 32-bit signed integer) in a function that requires it in another (eg a floating point number) by repeatedly converting it "on the fly" at each stage of the calculation rather than converting it once and then keeping it in that format.

A number of spacecraft have come to grief because a function that needed data in imperial units was supplied with data in metric ones (or vice versa), and of course an airliner ran out of fuel and had to land on a go-kart track (google "the Gimli Glider") for similar reasons. Typecasting errors are more common, but more difficult to describe in layman's terms.

But inappropriate software re-use is different. In the case of the Arianne V they decided to reuse chunks of the software from the Arianne IV because it was "proven" and would therefore be "low risk". Sadly the higher performance of the Arianne V took values beyond the "proven" range and the software crashed, followed shortly by the spacecraft.

Using odd fragments of code outside their original design context without a deep understanding of what each part of it does is generally deemed a dangerous practice for this reason - if you didn't design the code you don't know what its expected input bounds are, or how it will respond to unexpected conditions.

As for scientists writing software for anything practical - that always has to be regarded with suspicion. The Therac-25 fiasco is a typical cautionary tale in this area. A radio therapy machine was developed by scientists and used on real patients. The poorly designed software produced with no assurance processes by learned doctors who knew little about how to develop software properly resulted in massive radiation overdoses (as much as 2 orders of magnitude higher than expected) for many real patients. Some died, others were badly injured.

I'm not suggesting software is unique in respect to these errors - the first space shuttle crash was caused by a directly analogous inappropriate hardware design re-use. It's just that you don't often get unqualified people believing they can design rocket engines, where sadly it seems every man and his dog seem to believe they are qualified to "write code".

PDR

 
Leith
1337570.  Wed Nov 27, 2019 6:58 pm Reply with quote

dr.bob wrote:
If I employed a software engineer who tackled. say. a fourier analysis by dusting off his A-level maths textbooks and started coding from first principles, I'd recommend him for immediate reassignment to the janitorial department. Given that such problems have been solved multiple times by other (possibly better) coders in the past, it would be a criminal waste of time to not reuse some working code that was freely available on 'tinterwebs.


That's the difference between my line of work and PDR's. I work mainly on spacecraft ground segment / ground test systems like the one you describe. These are mostly non-safety-critical applications running on PCs or at least high-powered embedded systems. If I need to do a fourier analysis, I'll use whatever the established off-the-shelf library implementation is for the platform I'm working on, with the appropriate tests and audits.

PDR, I assume, is more involved with flight avionics and high-performance real-time control systems. The last time I had to write that sort of code, it involved writing an integer-arithmetic numerical approximation of a square root function (because it had to run on a system that didn't have capacity to perform real-valued arithmatic, never mind host a maths library). Due to severe resource contraints, my approximation was never going to be very accurate, but I needed to know that it would meet certain minimum criteria like being monotonic over the particular range of input values specific to that application, in order to be confident that the control loops would hunt and lock correctly.

That sort of job doesn't lend itself so well to direct re-use of software. At best you'll be able to make use of existing design patterns and techniques at a general level, but any control algorithm code is likely to be bespoke and heavily tailored to the specifics of your application.

Contrast with the majority of the mainstream software industry. In almost any commercial web, PC or phone application development activity, if you're not basing the majority of your software on existing platforms and libraries, you're likely to be out of business very quickly indeed.

 
Leith
1337571.  Wed Nov 27, 2019 7:33 pm Reply with quote

barbados wrote:
That about hits the nail on the head I was aiming for.
I would have expected the code to be written by people that know how to write code, not those that know how to “do science”


You always need some element of both software engineering knowledge and domain knowledge.

The most important element of any software engineering job is to be able to understand the wants and needs of your customer and how that relates to what you can deliver them.

I don't need to know every aspect of the physics of the missions I work on, but I at least need to have enough understanding that I can ask sensible questions about physics issues that have an impact on the software I'm developing, understand the answers, predict any areas of high risk or complexity, and have some insight into which of the features I could potentially implement are going to be of most value to the mission.

 
crissdee
1337593.  Thu Nov 28, 2019 6:08 am Reply with quote

Leith wrote:
writing an integer-arithmetic numerical approximation of a square root function (because it had to run on a system that didn't have capacity to perform real-valued arithmatic, never mind host a maths library). Due to severe resource contraints, my approximation was never going to be very accurate, but I needed to know that it would meet certain minimum criteria like being monotonic over the particular range of input values specific to that application, in order to be confident that the control loops would hunt and lock correctly.


I recognise that as English, but it might as well have been Mandarin for all it imparted to me....;-)

 
PDR
1337614.  Thu Nov 28, 2019 8:38 am Reply with quote

Leith wrote:

That's the difference between my line of work and PDR's. I work mainly on spacecraft ground segment / ground test systems like the one you describe. These are mostly non-safety-critical applications running on PCs or at least high-powered embedded systems. If I need to do a fourier analysis, I'll use whatever the established off-the-shelf library implementation is for the platform I'm working on, with the appropriate tests and audits.

PDR, I assume, is more involved with flight avionics and high-performance real-time control systems. The last time I had to write that sort of code, it involved writing an integer-arithmetic numerical approximation of a square root function (because it had to run on a system that didn't have capacity to perform real-valued arithmatic, never mind host a maths library). Due to severe resource contraints, my approximation was never going to be very accurate, but I needed to know that it would meet certain minimum criteria like being monotonic over the particular range of input values specific to that application, in order to be confident that the control loops would hunt and lock correctly.


That may be a part of it, but by no means all. Probablythe major driver is Information Assurance - being able to know absolutely everythig that's in your code. So on any "critical" application (be it safety critical, business critical, personal-data critical or WHY) it's difficult to use code produced by others. We only use library functions where we have compiled the library from source - that's the only way to be certain it contains no back doors or "phone home" functionality*, let alone adequate assurance that it actually does what it's supposed to and includes no unmitigated vulnerabilities. This should be obvious for things like flight-control software, weapon control software or nuclear reactor control systems, but it is at least arguable that any system which handles personal data cannot be GDPR compliant if it uses external functions without the ability to analyse and walk-through the source.

PDR

* We had a major panic a few years back because the supply chain for a particular brand of networking equipment had become poluted with grey market and cloned devices which did just that. It cost us £32m to purge the stuff from our own systems, and cost the MoD an order of magnitude more.

 
dr.bob
1337649.  Thu Nov 28, 2019 11:06 am Reply with quote

suze wrote:
I do not doubt that there is pre-written code readily available for just about every mathematical operation you're ever likely to need.

But is using it actually any better than believing what you read on Wikipedia?


Yes.

Back when I was young and programmers still actually read books, one of the main sources for such code was the "Numerical Recipes in..." range of books which were produced for a variety of languages. You can see Numerical Recipes in C here. The authors were from the Harvard-Smithsonian Center for Astrophysics, Cornell University, the Polaroid Corporation and EXXON and the book was published by Cambridge University Press. The code was written out in the book (also provided on a CD), so it met PDR's requirement of being able to compile the library from source.

These days, many libraries are produced as open source code (also meeting PDR's requirement of being able to compile the library from source) by teams of people, mostly university employees. These teams tend to include scientists who know how to design algorithms and produce unit tests, as well as expert programmers who know how to produce efficient, scalable, maintainable, and testable code. For instance, libraries to do things like fourier transforms in python are supplied by the SciPy group.

PDR wrote:
"Reusable code" is one of those fallacies that led to things like the Arriane 5 failure.


Does your organisation never reuse any code?

PDR wrote:
A number of spacecraft have come to grief because a function that needed data in imperial units was supplied with data in metric ones (or vice versa)


Is that number "two"?

I know about the Mars Climate Orbiter, and the DART mission (though I'm not sure even the second one is a good example since it was originally intended to be a low-cost, high-risk project and, as such, wasn't put through a sufficiently rigorous testing regime). Were there any others?

 
barbados
1337654.  Thu Nov 28, 2019 12:15 pm Reply with quote

dr.bob wrote:

PDR wrote:
"Reusable code" is one of those fallacies that led to things like the Arriane 5 failure.


Does your organisation never reuse any code?


I would suggest that is an example of not knowing how to format the code correctly in the first place.

 
PDR
1337718.  Fri Nov 29, 2019 9:36 am Reply with quote

dr.bob wrote:

Does your organisation never reuse any code?


Never is a strong word and I couldn't make such a claim because I don't see every single piece of code that we produce.

But code with any significance (safety, technical, business) must be written in accordance with coding standards documents and all of the ones I've seen around here explixitly prohibit reusing binaries (executables or libraries) and put lots of additional assurance activities around reusing source. What we DO reuse are algorithms and math flows - these can be incorporated into new projects because things like bounds checking, exception handling and type mismatches will inherently be addressed in the subsequent verification stages.

This is expecially true where object-oriented methodologies are involved, where where the code is so obfusc in respect to its function that it's rarely useful to try code inspection to determine what it actually does - inspecting the use case models, class diagrams, activity diarams, state diagrams etc can be useful and model fragments at THIS level can be shared, but reusing at source level is regarded as risky and binary level is verbotten.

These days pretty well all of our "serious" software is developed using Model-Based Systems Engineering methods, using SysML/UML to capture, analyse and design required functionality. The actual code generation is a relatively trivial activity using these approaches (indeed often done using automated code generation), so any reuse is almost inherently at the very high level only.

Thinking about it the one group of people I know of who DON'T do this are the business software teams to are doing our ERP migration programme. But that programme is currently 4 years late and nearly £1Bn over budget (EAC), and the partial implementation that has actually been rolled out s riddled with inexpected behaviours. I've heard annecdotally that they championed code reuse as one of the big benefits of their proposed approach back when the project was started (back in the late paleozoic era).

PDR

 
barbados
1337720.  Fri Nov 29, 2019 9:40 am Reply with quote

If you don't reuse code, how do you acheive backward compatibility?

 
cornixt
1337995.  Mon Dec 02, 2019 11:27 am Reply with quote

Leith wrote:
The most important element of any software engineering job is to be able to understand the wants and needs of your customer and how that relates to what you can deliver them.


This is a key part. I recently had to talk a customer out of several features that they asked for. They would have ended up with that weird feeling in your stomach when you briefly enter zero-g, but this would have happened on every aircraft descent. The unpleasantness wasn't the big issue though, it was dropping into airspace that they weren't cleared for because it would overshoot the flight level. They were asking for something that sounded good on paper, but when implemented the flight characteristics do very different things. Instead we gave them a much smoother method - but it took them some convincing because they were certain that their idea would be best.

 
PDR
1337996.  Mon Dec 02, 2019 11:34 am Reply with quote

barbados wrote:
If you don't reuse code, how do you acheive backward compatibility?


Backward compatibility is not required for (or related to) code reuse.

PDR

 
barbados
1338006.  Mon Dec 02, 2019 12:07 pm Reply with quote

You're correct in your comment - but I suspect you have put it the wrong way round ;)

Are you suggesting that your employers would rewrite all of the code for an application that previously only adjusted the angle of the dangle, but can now measure the heat of the meat and compare it automatically to the axis of the maxis (even though the gravity of the cavity reading needs manual intervention*

*other applications are available but for an updated application to continue to work on a legacy device you would need to have code specific to that device (see your earlier example of Arianne 5)

 
PDR
1338007.  Mon Dec 02, 2019 12:12 pm Reply with quote

Applications are maintained at the functionality/model level, not at the code level.

PDR

 
barbados
1338010.  Mon Dec 02, 2019 12:17 pm Reply with quote

I think we're talking about apples and oranges ;)

 

Page 4 of 6
Goto page Previous  1, 2, 3, 4, 5, 6  Next

All times are GMT - 5 Hours


Display posts from previous:   

Search Search Forums

Powered by phpBB © 2001, 2002 phpBB Group