The Advantage of not having Hardware yet.

Embedded software development usually involves custom hardware. Consequently software and hardware are developed concurrently. My first XP project, back in 2000 was an embedded project. There was no hardware. We developed on a PC. The system was a communications control system. On one side of the systems was a WAN. On the other side of the system was a custom communication media; the legacy communications media. The sub-system we were building had about five or so collaborating systems that were being built by other teams. The other teams were using a traditional waterfall development process.

The usual way for teams at this company to build software was to spend a lot of time developing the design on paper or in a case tool. This was a BDUF culture. We were doing XP, so we were determined to let the design evolve incrementally. We did what we called LDUF, yes, Little Design Up Front. Each iteration we spent a few hours planning the iteration and updating our architectural vision. This vision kept the whole team moving in the same direction.

The project management wanted to know how concrete progress could be made on the embedded software before there was hardware. BDUF project teams made progress through documentation. The XP team made progress through demonstrable code and tests. We employed interfaces and mock objects at the boundaries of the sub-system. Events could be fed to the system, and its response verified. These constructs provided a demonstration of progress in core application code. This core application provided the same business rules as the legacy code it was replacing.

As the design grew and we needed something that was provided by another team or by the hardware, we created an interface. The interfaces were simple. In C++ they are base classes with all pure virtual methods. They exposed no detailed knowledge of the hardware or the other teams’ implementation details. They were just the essential view of the service needed by our sub-system from the other sub-system or hardware.

If we had the actual hardware, I expect we would have seen implementation details in the interfaces that accessed the hardware. The design would have been made more concrete because of our knowledge of that hardware. We probably would have known the bits to fiddle to get the hardware to generate the controls signals needed. Because we had no knowledge of those bits, those implementation details never worked their way into the interfaces.

The interfaces were abstract, and would much better stand the test of time. Mock Objects filled in for the real implementations. We were able to verify the inner workings of the system through generating events and seeing how the system responds thought the mock objects.

When hardware finally was available adapters were written that tied the logical interface, our abstract interface, to the detailed implementation of the hardware. We could finally test in the real environment. Our interfaces and mock objects got us a long way. As a consequence of our testing diligence very few problems with the core application are found in the target.

Well, now that there is hardware, should those tests and mock objects be discarded? Absolutely not! As we evolved the application the test and mocks also evolved. The proper operation of the system could be tested in the friendlier development environment. This does not mean tests are not needed for the fully integrated target, but most of the problems are found and eliminated prior to testing in the target. Side effect defect are found, as our mistakes are announced by the failing unit and acceptance tests.

At first, not having target hardware seemed like a real liability. As it turned out not having hardware was actually a luxury. Design could go on without waiting for hardware interface details. The changing hardware details did not ripple through the system. Abstract interfaces stopped those changes in their tracks.

In reflection, if the original system that was redesigned, had abstracted the hardware,a major redesign would have been unnecessary.

!commentForm