In February I moved back to NICTA after what proved to be an interesting sabbatical year working at Saluda Medical. Saluda is going strong – they have great technology, and very recently closed a $10Mill VC round which will lead towards major clinical trials of their implanted spinal cord stimulator in the US.
I learned a lot working at Saluda, which is always fun – I hadn’t previously worked alongside mechanical engineers on product design, nor alongside electrical engineers doing signal processing, nor thought much about manufacturing process and product validation for manufactured devices. My role included work defining user requirements, system specifications, system architecture, system validation, and system verification. But perhaps the most interesting thing was risk management, which is central to systems engineering and is highly interdisciplinary. The system I was involved with is now undergoing clinical trial in the US. I also contributed to my first (very cool) patent application, and helped co-author a (conference) publication on placement of paddle leads for spinal cord stimulation. There is perhaps another (journal) publication in the works on adverse events for spinal cord stimulation. And I had the opportunity to learn Python, which was fun, and to learn more about Microsoft Word Interop scripting than I ever wanted to know.
The medical device industry has an interesting regulatory environment. Of course it’s very conscious about risks and ethics. However, there is a surprising amount of flexibility about how companies can choose to engineer medical devices. Nonetheless, when a company has said how they’ll demonstrate safety and/or effectiveness (and having had that plan approved), regulatory monitoring and review is a powerful way of making sure that happens. That’s especially pointed when companies are selling medical devices (which Saluda hasn’t yet started to do).
In January, the the journal Synthese accepted and published the first of two papers of mine on the philosophy of engineering. The second installment is now also accepted and published: “Critical rationalism and engineering: methodology” (author’s preprint here). Woot! In the new paper I use the three worlds schema from the first paper to look at possible sources and responses to falsification of engineering theories. I also discuss the growth of knowledge in engineering. Finally, I talk about assurance in engineering. There are perhaps more open questions than answers, but the questions are important and interesting.
Assurance is key for engineering. Engineers design and create artefacts that other people use. But engineers don’t just throw artefacts “over the wall” (or into the market) – they also warrant that those artefacts can be used to meet people’s needs. Those assurances don’t just get made up. They are backed by explicit justifications – arguments using empirically-validated engineering theories. For safety-critical systems, if those arguments are invalid or those theories are false, people will die or get hurt. That’s why it’s worth understanding engineering epistemology.
Today I’m starting in a new role as Systems Engineering team lead at Saluda Medical – a medical device startup company. We’re working on a new technology for closed loop control for spinal cord stimulation that will target the treatment of Chronic Neuropathic Pain. This is a great group of people and a technology with huge potential. Saluda Medical is a spin-out from NICTA, where I’ve been working for the past ten years. I wasn’t part of the Implant Systems team before they spun out, but I was cheering loudly from the side-lines, so I’m very excited to be part of the team now.
NICTA’s been a fantastic place to do world-leading research, and to think about how that can lead to international impact and ultimately benefit Australia. I’m happy I’ll still retain an association with NICTA – mostly to help close out some PhD student supervision but also to finish off a few pieces of research collaboration.
It’s sort of ironic that the very week my first philosophy of engineering paper was published was the same week I started the move back to industry! But it’s all about engineering.
What is engineering? Sometimes people think engineering is just the same as science, but in a new paper on the philosophy of engineering (preprint here), I argue why that’s not the case. Engineering is similar, but different to Science, and its epistemological issues are also similar but different.
I got into this question because of problems in assurance for software engineering and formal methods that are essentially philosophical problems. But having work available on the philosophy of engineering available should also help with perennial questions like “Is Software Engineering a field of engineering?” and “Is Computer Science a science?”.
Wow – more than a year between homebrews, again. I’ve almost depleted my stores, which gives you some idea of how much I’ve been drinking and socialising over the past couple of years (not much of either). I find old homebrew basically gets better with age, but maybe I’m pushing it with some of the 2 year-old beer. Anyway, again (but not by design) I’m doing a Cooper’s Heritage Lager, but this time with a Cooper’s Light Malt tin as the adjunct. O.G. is around 1.042.
Almost a whole year since my last brew (which has worked out great, BTW). Inspired by a colleague’s homebrew at Friday afternoon drinks, I’ve dragged a kit off the shelf to start another brew. This time it’s a Cooper’s Heritage Lager, with 600g Dextrose and 400g Maltodextrin. Nothing fancy. O.G. is somewhere around 1.042 to 1.044.
Don was an Apple II kid, and he credits Apple with helping him dive so deep and so early into writing software. I never had an Apple II, but I got a taste of that kind of experience with the Vic-20 at home, and the BBC computer room at school.
But then, we upgraded our home computer to the Apple Mac. My experience on the Apple Mac was exactly opposite to Don’s on the Apple II.
The Mac was the start (well, after Lisa) of Apple’s focus on the creativity of the users of computers, rather than on the creativity of software developers. The Mac had amazing useability and rich interactive applications, but there was no out-of-the-box development environment. Even when years later I did get the MPW, there was a killer learning curve to create simple apps that conformed to Apple’s strict UI guidelines. Hypercard (especially Hypertalk) was ahead of its time and did encourage bespoke coding creativity, but then Apple ditched it.
Apple’s success is due to their user and customer focus, but ever since the Apple Mac they’ve been mostly hostile to developers.
Something to do with all the mandarins from our tree – a Hoegaarden-inspired mandarin-and-coriander wheat beer. Cooper’s wheat beer kit, light dry malt, peels from 6 mandarins, and 2.5 tblsp coriander seed. (All a guess – let’s see how it turns out.) O.G. is 1.040.
Marek Kowalkiewicz from the SAP Research in Brisbane just last week won the international “Demo Jam” competition in the SAP TechEd event in LA, for the “Innoboard” software. Innoboard is an augmented reality technology, which lets distributed teams interactively share whiteboards that mix projected images and physical sticky post-it notes. All using the low-cost iphone camera and an ordinary projector. Cool demo! The idea at the end of taking streamed information out of the interactive session and using that to drive other workflow software (Jira in this case) is also cool, and just hints at the huge potential of ideas like this.
The Innoboard team found its first industry trial partner through the Future Logistics Living Lab, which is run by NICTA, SAP, and Fraunhofer IESE, and has around twenty (and growing) industry & research participants. (Fraunhofer’s involvement is through the Fraunhofer Project Centre in Transport and Logistics at NICTA). Industry trials for Innoboard are continuing, in a use-case for distributed logistics operations planning. The Future Logistics Living Lab is also hosting a demo instance of Innoboard, and setting it up in the lab has helped contribute to ironing out some of the use & set-up issues in the early prototypes.