About this Case Study
One of the 12 principles of agile states that we should:
“Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”
This proves to be very difficult to achieve when working with hardware; even the most minor of changes can result in a complete rework of a printed circuit board! What is it about hardware that makes it unamenable to the agile approach? And more importantly, does it need to be this way?
As an agile software engineer, with several years’ experience working in the embedded sector, I have witnessed how software and hardware can often conflict. I aim to share my personal experiences of what it is that causes this friction.
I will provide instances where software and hardware have been developed side-by-side with little friction, and highlight the ways that we can foster a better development process by aligning these two areas.
Minor changes in hardware can provoke major changes in software, ie a change in computer chip can result in rewriting an entire driver. I aim to offer tools for the software engineer to aid in making their software responsive to change, drawing on solid design principles to minimise the amount of rework necessary.
I will offer insight into how to align software when different members of the team may be working on slightly different iterations of the hardware, even when employees may be working in different locations.
Traditionally we perform software and hardware development in isolation; the hardware engineers will design the hardware, and then the prototype hardware is given to a software engineer, with a manager mediating interactions between the two. I will explore how encouraging direct collaboration and interaction between these areas can result in a better product, minimising the amount of rework needed.
It is often stated that TDD cannot be done for embedded software. I will also explore how we can remove the dependency upon hardware by mocking hardware components, allowing for more comprehensive testing.
I will explore how, by removing this dependency on hardware, we can provide continuous integration for our embedded projects, thus providing greater software agility. I will show how it is even possible to perform continuous integration, so that the unit tests can be validated directly on hardware.
About the Speaker
Christopher Burdett-Smith-Whitting is a software engineer at Zuhlke Engineering with over 5 years of programming experience working in the embedded sector. Having started his embedded career working on designing safety critical systems for the railway industry, he is passionate about exploring how to apply agile to the electronics industry in order to develop safer, more robust electronic devices.