The team members are familiar with:

1. Power industry requirements for reliability, protection and safety.
2. Software and Systems Methods for ensuring high reliability and availability.
3. Test design and implementation including automated testing systems.

There are a quotes and references below which describe some of the background.

Some thoughts on high reliability from Stephen Wilson at Lockstep

Stephen Wilson and Phil worked together on one of the first software controlled implantable defibrillators. This had moderately high reliability requirements and Stephen summarises some lessons learn as:

I was a software development manager for some years in the cardiac pacemaker industry.

We developed the world’s first software controlled automatic implantable defibrillator.

It had several tens of thousands of lines of C, developed at a rate of about one tested line of code per person per day.

We quantified it as the most reliable real time software ever written at the time.

I believe the outstanding quality resulted from a handful of special grassroots techniques:

1. We had independent software test teams that developed their own test cases and tools
2. We did obsessive source code inspections on all units before integration and in the end, before we shipped, we did an end-to-end walk through of the frozen software. It took six of us two months straight. So we had several people who knew the entire object intimately.
3. We did early informal design reviews. As team leader, I favoured having my developers do a whiteboard presentation to the team of their early design ideas, no more than 48 hours after being given responsibility for a module. This helped prevent designers latching onto misconceptions at the formative stages.
4. We took our time. I was concerned that the CASE tools we introduced in the mid 90s might make code rather too easy to trot out, so at the same time I set a new rule that developers had to turn their workstations off for a whole day once a week, and work with pen and paper.

My internal coding standard included a requirement that when starting a new module, developers write their comments before they write their code, and their comments had to describe ‘why’ not ‘what’. Code is all syntax; the meaning and intent of any software can only be found in the natural language comments.

1. http://lockstep.com.au/blog/2014/02/26/gotofail.htmlgotofail and a defence of purists - another Stephen Blog where ]Phil] gets to pretend to be the accumulator :-).

Its worth noting that not all software has this level of requirements but the ideas have been used in the development of most of our systems.

One minor point to note is the 1LOC/d/developer doesn't include:

1. Test systems, e.g. we developed a test suite for every code sequence generated by a single rule in the compiler.
2. C Compiler based on the Amsterdam Compiler Kit
3. CPU validation