Many developers build applications organically to meet changing user demands – but this approach, according to one of the operating system world’s biggest luminaries, isn’t always compatible with building the best software.
“There are only two kinds of software in the world,” Butler Lampson – a highly decorated software engineer for nearly 60 years, recipient of a Turing Award, operating-system designer, developer of widely-used IT security methods, and designer of fault-tolerant systems – explained during a recent online talk at the UNSW Faculty of Engineering John Lions Distinguished Lectures series.
‘Precise’ software, he explained, satisfies particular specifications – think avionics software, banking systems, and Microsoft Office – while ‘approximate’ software is just designed to work.
“The important thing for an approximate system is that you get it soon and that it’s cool,” he said, citing the ever-evolving worlds of online search, shopping, and Twitter.
The problem with approximate development, however, is that its imprecise nature violates the computer-science philosophy that software is intended to solve clearly designed problems.
“The natural instinct of a computer scientist is to say that precise software is good and approximate software is sloppy and bad,” Lampson said.
“I don’t think it’s true that one kind of software is better or worse – but I do think that they’re very different.”
“If you don’t realise what kind you’re writing, you’re going to get into trouble,” he continued, “because you’re either going to do too much work to satisfy a spec that customers don’t really care about – or you’re going to do too little work and fail to satisfy a spec that the customers do care about.”
The key to good design
Ultimately, Lampson said, developers must think about code as “being” – a reference to static information retrieval, such as with databases – or as “becoming”, in which functions are created by using tables, code, or overlays to produce an outcome.
“If you’re not able to write down the state of your system in this kind of language,” Lampson said, “then you really don’t know what you’re doing.”
“And in spite of that, it’s surprisingly rare that people actually do this – and even more rare that it shows up in documentation intended for clients of the system, which makes it very difficult to figure out what the system is actually going to do.”
Good design also means using standard interfaces and abstraction layers that allow code to be reviewed and enhanced without getting lost in minutiae.
“When the system evolves, the only thing that’s going to save you is abstractions and interfaces,” Lampson said, “because those are the only techniques that we know of for making sense, and keeping the parts simple enough that you can understand them.”
Five key factors help make systems more adaptable over time, with the first four – modularity, automation, concurrency, and dependability – reflecting software’s ability to satisfy the precise needs of its design brief.
And the fifth factor? Lampson calls it, simply, “yummy”.
“This means that your users really want your system,” he explained.
“There are two major ways to achieve that: either make sure the system has some function that users really want, or do really good design.”
When is software too mature?
Operating systems don’t come much more precise than seL4 – a CSIRO research project that began as an embedded-systems operating system in 2006 and in 2009 was mathematically proven to be functionally correct against its specification.
That meant it did exactly what it was supposed to do – nothing more, nothing less.
It made seL4 an ultra-reliable architecture suitable for everything from drones to trustworthy computing architectures – which is why many were surprised when the CSIRO last month announced it would wind down the Trustworthy Systems group responsible for seL4’s development.
Yet seL4, which a CSIRO spokesperson called a “mature area of technology”, has been transitioned to the global seL4 Foundation and is gaining favour amongst Internet of Things (IoT) developers – who, Lampson said, must innovate while meeting one basic goal: “don’t kill people”.
“Everything else is secondary,” he said, “and while this is not a huge problem now, it’s quite clear that it’s going to be a problem as computer-controlled devices become more and more embedded in the physical world.”
Safe devices, he said, “need two things: a secure foundation, and a sound architecture.”
‘Sound’, in this case, means that like seL4, that architecture does exactly what it was designed for, nothing more, and nothing less – a rare thing in a world where operating systems are continually changing and expanding to add new features.
Such ‘approximate’ development may be acceptable in ‘good enough’ environments like the Internet, IP data transmission and web browsers – all of which continuously balance preciseness with function.
“What I like to say about the web is that the reason it’s successful is that it doesn’t have to work,” Lampson explained.
“When you try to make the web client be a machine, you have to be extremely careful because the thing is not designed to work all the time – and machines, typically, are not very comfortable with that.”
“But the fundamental assumption [online] is that when the client is a person… you don’t have to get the right answer; you only have to come close enough.
“And [sometimes] a good-enough answer is all you need.”