The ability to work remotely in Embedded is a sign of software engineering maturity: https://anisse.astier.eu/embedded-software-maturity.html ; Let me tell you the story of how I arrived at this thought. 1/14

Almost ten years ago, I was at a talk by @srostedt on ktest .pl for kernel build and testing automation. He talked about his setup which included an automated power switch, as well as a special adapter for using the EHCI debug port, which is a serial port for x86 machines 2/14

I remember feeling at the time that it was rocket science, and I had no idea how to obtain any of those. And even though I was working with x86 hardware, I dismissed those as useless for my uses. Youthful mistake. 3/14

Over the past years, I've seen the rise of "board farms" for kernel developers. Many people were building one and converging on LAVA; most people used power switches that needed opening the power supply cables though. 4/14

As I moved to the Set-Top-Box industry, I noticed the use of @Witbe robots. But their use was far from deployed on every project, nor integrated with CI. And they had many limitations at the time, with UHD, higher framerates, HDR or radio (zigbee/bluetooth) remotes. 5/14

That's a proof that you might have a solution one day, and regress the next; especially if you worked on project-by-project basis and let all your contractors go regularly. 6/14

I've noticed this too when changing contracts. Teams that suffered high member turnover often lost advances they had like CI, and automation. IMO this is often because this automation was always custom-built and therefore high-maintenance. 7/14

Everyone is building their own (incomplete) solution. With Farjump @Juli0Guerra attempted to solve this at some point, but I'm afraid that finding a market fit in this domain can be quite hard, especially when targeting the very price-sensitive consumer electronics market. 8/14

Industry might be interested, but for that they'd need to see the value of modern software development. Even I didn't believe in it at the time, seeing custom built solutions as more than enough. 9/14

A few weeks ago, before Oxidize 1k, @bitshiftmask made a few remarks on what constitutes the basics of modern software engineering, and how embedded was getting (almost) none of that. 10/14

I've noticed that too, as I once consulted for a small company that was doing Linux development with an outdated Yocto like they were building Windows programs in the 90s: copying `.so` files around and putting them on the target, and then calling it a production image. 11/14

Needless to say, I've very strongly advised against this, and gave clear guidance of the first steps to take (hello, git), but they didn't have enough budget to fix their core development issues. 12/14

In a sense, I didn't think I should be writing this — it might seem obvious — but reflecting on what I've seen of what happen in "the real world", it isn't obvious to everyone. 13/14

Although I started the draft of this article at the beginning of lockdown, I have been quite busy in the past weeks. But at least it wasn't because I couldn't reach the hardware sitting on my desk at work. 14/14