[Reading time: 2 minutes 13 seconds]
Today I had an interesting conversation with a LinkedIn contact, CEO of a company specialising in embedded systems.
He echoed a sentiment I encounter very often in embedded systems:
“Haha! Applying DevOps to embedded sounds great but 10 years away from now :-) Security, resource requirements, … "
I think he made it too easy for himself to dismiss it that easily out of hand, but I suspect he was just trying to bait me into a discussion :-D
Well, he succeeded. 10 years away, let’s see…
First, realise that you’ve got to start somewhere. Maybe not everything makes sense for embedded, and trying everything at once is certainly too much, but I think we agree that in many teams development practices could be better than what they currently do.
So I think you might be 10 years away from everything (whatever you consider everything), but you’re only minutes away from making tomorrow better than today. And then you repeat.
Second, maybe not everything that makes sense for e.g. web development makes sense for embedded. That’s OK.
Certainly you’ll need to tailor DevOps to your situation, your reality, your product, your use case. Don’t worry about what some blog post tells you “should” be done; find the thing that makes sense for you, right now, and do that. And then you repeat.
DevOps is not a goal, or a set of practices, but a process.
But, and I think that’s the crucial part: in my opinion DevOps is nothing new at all – it’s just an implementation of time-tested good engineering practice:
- short iterations (as short as feasible, obviously)
- fast feedback
- experiment-/prototype-driven development
- aiming to automate tedious work, preserving focus and valuable human thought for the hard problems
All with the goal of de-risking development. Again, that’s simply good engineering practice, regardless of whether you’re building bridges, ECUs, or webshops.
While I completely agree that many teams still have a long way to go, some are already living 10 years in the future.
Indeed, 60 years ago some teams were living in the future already. I was fascinated by Ben R. Rich’s book “Skunk Works”. The people at Lockheed Skunk Works implemented approaches that we might call agile today, long before the term was invented – just because it made sense to the engineers.
And they were able to build iconic, supposedly impossible planes in outrageously short times (I seem to remember U-2 took 18 months(!) from signing the contract to first flight in service. That’s impossibly short for aircraft manufacture).
William Gibson put it eloquently:
“The future is already here, it’s just unevenly distributed”.