Archives For Complicatedness

Here’s a view from inside Tesla by one of it’s former employees. Taking the report at face value, which is of course an arguable proposition, you can see how technical debt can build up to a point where it’s near impossible to pay it down. That in turn can have significant effects on the safety performance of the organisation, see the Toyota spaghetti code case as another example. The take home for this is for any software safety effort it’s a good idea to see whether the company/team is measuring technical debt in a meaningful fashion and are actively retiring it, for example by alternating capability and maintenance updates.

Tesla and technical debt.

https://mobile.twitter.com/atomicthumbs/status/1032939617404645376

AI winter

Here’s a companion tutorial to the one on integrity level partitioning. This addresses more general software hazards and how to deal with them. Again you can find a more permanent link on my publications page. Enjoy 🙂

Boeing 787-8 N787BA cockpit (Image source: Alex Beltyukov CC BY-SA 3.0)

The Dreamliner and the Network

Big complicated technologies are rarely (perhaps never) developed by one organisation. Instead they’re a patchwork quilt of individual systems which are developed by domain experts, with the whole being stitched together by a single authority/agency. This practice is nothing new, it’s been around since the earliest days of the cybernetic era, it’s a classic tool that organisations and engineers use to deal with industrial scale design tasks (1). But what is different is that we no longer design systems, and systems of systems, as loose federations of entities. We now think of and design our systems as networks, and thus our system of systems have become a ‘network of networks’ that exhibit much greater degrees of interdependence.

Continue Reading…

Interesting, and a little weird. From Krebs on Security the strange tale of Loren Ipsum and Google.

Well I can’t believe I’m saying this but those happy clappers of the software development world, the proponents of Agile, Scrum and the like might (grits teeth), actually, have a point. At least when it comes to the development of novel software systems in circumstances of uncertainty, and possibly even for high assurance systems. Are you insane I hear you ask!? Well quite possibly, my mother never had me tested, but leaving that aside we should always take the opportunity to look carefully at what are the un-questioned certitudes of the discipline when a fresh perspective arises.

And in this case the Agile crowd take aim and attempt to skewer one of the central tenets of software engineering, that plans (and documents) are inherently good. So let’s stop and ask ourselves why do we think that this is so? Certainly you might need some sort of plan for the delivery of a +10 million lines of code on the JSF, but do we really think that a vision of the final product was visited upon the management team day zero, and the rest was filling in the gaps?

If the honest answer is ‘no’ to that question on day one, followed by a ‘we really don’t know’ on day two then perhaps the wisest thing is not to sit down and write a 200 page software plan that is based on the lessons of the past, but instead focus upon what Karl Weick called the process of organisational sense-making, and mindfulness. In this Agile, which espouses collaboration, communication and responsiveness to change within a framework of small builds may have a significant advantage over traditional grand strategies in situations of FUD (Fear, Uncertainty and Doubt). When you don’t know what to do, don’t sit down and plan what you don’t know, get people moving, talking, collaborating and making stuff. Then out of that activity you’ll find the information will emerge that will allow you to make decisions.

As Tom Peters points out we need to understand whether our methodologies have an inherent bias for action or a bias for planning, and then whether the situation is complex (but understood and stable) where planning will pay off or uncertain (with high novelty and volatility) where talking, thinking and looking at the small grain issues to build a picture of where we are is what we ought to be doing.

So for that insight at least, the Agile community gets two hallelujah testify moments out of five…

Toyota ECM (Image source: Barr testimony presentation)Economy of mechanism and fail safe defaults

I’ve just finished reading the testimony of Phil Koopman and Michael Barr given for the Toyota un-commanded acceleration lawsuit. Toyota settled after they were found guilty of acting with reckless disregard, but before the jury came back with their decision on punitive damages, and I’m not surprised.

Continue Reading…