Piero Bosio Social Web Site Personale

I may have accidentally started writing a weird book on epistemology. Oops.

You don't need to be working on nuclear safety for this to all be relevant. Your risk tolerance is likely much lower. On the other hand, don't you want know what you expect out of a code and whether it works to the degree you need it to work?

How many popular programming books talk about installation, acceptance, and in-service testing even 5% as much as they talk about unit testing? How many scientists snd engineers who write or use software know how to test and evaluate their codes - acquired or internally developed? Even if the vendor hands you a set of acceptance test cases and reference results, how well are they documented? Do they actually test what needs testing? Do they adequately test features critical to your use case? Can you make a convincing case that the software is fit for use?

I want to pose these very basic questions as a very gentle intro to software quality assurance to people who wouldn't voluntarily touch a book on SQA. It's intended to make practitioners (code developers, those who run the codes, and those who rely on the results) ask these basic questions and lead them toward getting answers. If you know someone downstream will/could/should be asking these questions, how does that change your coding practice? Can you make life easier for people downstream? Can you make life _safer_ for people downstream? Can you build that outlook into your practice so you are writing safer and more dependable code out of habit?

Unit tests are great but if they aren't thorough enough (and with rare exception they aren't), they have limited utility. Devs are bad at testing their own code - too little time, too much emotional and ego attachment, not knowing how or what to test. Nobody will pay for dedicated testers and managers are content with basic functional tests if it means they can ship on schedule.

Do you document your unit tests? How well? Do you share this with your customers?

A fun question to ask is how to tell whether a code _works_. There are two critical unknowns: the definition of "works" and "works for whom". A developer may make the naïve assertion "it passes the unit tests therefore the code works". Which is nice and all but nowhere near sufficient. How does a third-party non-developer verify the code works? In the space I work in, this is the more pressing question. The code passing its unit tests is a good sign; it's evidence of good software development practices but it does nothing to tell me if the software is fit for use in my application. That requires that I know my intended use and that's ideally something a developer should know but probably doesn't. If the developer knows their code is used in a safety critical context and they have even a fragment of professional ethics, they will consider whether their unit tests are thorough enough.

I want to set up some fundamentals. For example, I need to specify what kind of software I care about (high-integrity analytical software, a subset of scientific software), who uses it, and what for. This won't match what most programmers or scientific programmers work on but it's important for them to know these kinds of codes exist and regardless of their intent, these are codes they may inadvertently produce. Sort of the scientific software version of Randal Monroe's mythical programmer in Nebraska.

I started work on a new manuscript today. No idea how well it will pan out or how saleable it will be, but I do know it will be dramatically more saleable than my last proposal.
Basically, the premise is to gently nudge scientific and engineering developers toward writing high-integrity long-life code. It's still aimed at the #RSE market (which I didn't realize had a name in 2021) but it's focused on a different aspect of the legacy code problem.
In this case I'm explicitly trying to help people write _legacy_ scientific code - code that is good enough at its job that it's difficult to displace and is mature enough to be generally trusted.