[trustable-software] Exploring the "Hypothesis for software to be trustable"

Paul Sherwood paul.sherwood at codethink.co.uk
Tue Jan 23 11:53:39 GMT 2018

Hi all,

I've updated the doc I shared a couple of weeks ago [1] to reflect the 
discussions we had here about requirements.

Also, I keep being asked "what does good look like" for software 
projects, so I've started a new short document [2]. I'm trying to state 
some general principles which are in my view correct. I'd be delighted 
if anyone here can challenge/disprove/improve anything in the text, or 
suggest additional things which are irrefutable:

# What good looks like:

Everything is:
- documented in writing, declaratively as
   - sentences/statements
   - configuration
   - scripts
- version-controlled
   - with evidence of independent reviews
- cycle-time optimised
- originated as an issue/change
- specified and designed for availability and scale from the start

Specifications state:
- the problem
- the expected solution
- how to verify the solution

Construction is:
- declarative
- deterministic
- reproducible (at least functionally, ideally bit-for-bit)
- traceable with custody
- via shared ci pipeline infrastructure
- including all dependencies

Deployment + operation is:
- scripted/automated from the construction pipeline, including
   - atomic update
   - atomic rollback
   - atomic recovery



More information about the trustable-software mailing list