posted on: 02.02.2017
Tomaž Nahtigal

Author:

Tomaž Nahtigal

Lead Engineer

Building Embedded Software is Like Building the Tower of Babel

Working at Comtrade Digital Services is exciting because you come across a wide variety of software projects from different domains. In this dynamic working environment you are inevitably exposed to practices like Continuous Integration, Continuous Deployment, DevOps, Agile…

But for someone coming from an embedded background, they were more buzzwords than viable practices that can be used in the development process. Why is this so?

That’s because dealing with HW is hard. When you work directly with bits and bytes on the low- level of abstraction, you’re not just dealing with the “logical” aspect, but you need to consider electronics/physics, sometimes timing and layout in addition to program logic.  Errors are generally  hard to find/fix and most importantly the feedback loop when something goes wrong is typically slow, costly and fuzzy.

To quote a post on HN: “Why hardware development is hard: the physical world is unforgiving

But this is only half of the story, the reluctance to adopt new practices also has a lot to do with preconceptions that are present among people working in embedded.

Building embedded software reminds me of the tower of Babel.

Building embedded software (or any kind of software for that matter) is sometimes a curious endeavor. It often reminds me of the story of the tower of Babel.

Nowadays software development is a team effort and in a team there are different roles. To keep it simple I’ll mention only the 3 most typical: the developer, the tester and the project manager. Each role has its own (technical) language and its own agenda.

The success of a project often depends on the “culture” of the team and how well they understand the motivations of the different roles. How to establish an effective team is not a trivial matter and probably deserves a separate blog post. For now let’s focus on the preconceptions present in an embedded development team, that can sometimes hinder the process of finding the right solution.

 

 


I’m writing this blog to challenge some of the preconceptions, to show some examples how to improve the software development process in the embedded world. It is intend as a series of short blog posts, where each post will be presenting some examples of good or bad practices. There is no particular order in which the topics will be presented and I will also invite more contributors to the “Embedded corner”. So stay tuned!