@amoroso I'm trying to write one book that has a chance of being salable. I've spent a lot of time thinking through the scientific software recovery and refactoring process. People who care about that have been encouraging but I had a nice meeting with Bill Pollock of No Starch Press and we couldn't find a big enough market to make it pay for itself.

I tried to reframe the problem as understanding the big picture of what these codes do and why that is (or was) valuable. Show legacy and modern ways of handling the same needs so the reader gets something useful whether they are writing new code or refactoring something old.

That seemed to be missing a lot of context as to the core philosophy of why we need certain functions or facilities and why systems need to be built or documented or tested a specific way (e.g. unless they are well-documented and comprehensive, unit tests aren't adequate as acceptance tests. Unit testing is a development activity, not a qualification or V&V activity.)

So I backed up a further level, trying to summarize the process of engineering analysis (vs design or operations), looking at the artifacts of that process (technical reports and calculations), and explaining how aspects of the software support the creation of those artifacts. There are hard rules that apply to all aspects of analysis including software: cite your sources, state your assumptions, show your work, clearly define terms and show units of measure, state limits of applicability, ensure the work can be independently verified _in practice_.

That last one is key for large spreadsheets. In theory one could independently check the correctness of every spreadsheet cell (each of which is a line of code). In practice, a reviewer can't verify more than a few thousand cells and the spreadsheet should be converted to a traditional auditable application. Once you lay out the characteristics of dependable trustworthy analysis software, it becomes glaringly obvious that Excel is not fit for purpose. The convenience of construction is offset by the intractability of testing, review, configuration management, documentation, testing, etc., etc.

The book idea shifted from being purely about computation to primarily being about the engineering analysis process and how to design and implement software for that environment. I think that makes the book applicable to a much wider audience and helps bridge the gap between developers and analysts. It's especially important for researchers writing code because often those systems take on a life of their own and get used in environments the code authors don't understand. Knowing the restrictions and requirements on production engineering code would help avoid a lot of serious preventable problems when creating research software.