I’ve been an advocate of using feature teams instead of component teams for a long time. Back in the 1980s and 1990s, when I was working on embedded systems using 8-bit microprocessors, I often did both the hardware and software development. The easiest way I found to work was to develop both in parallel, adding complete functionality feature by feature. Working in this fashion also gave me great insight into choosing whether to implement a particular bit of logic in the hardware or software. Sometimes a software implementation could save a lot of expensive hardware, and other times a small bit of hardware could save a lot of software or provide better performance. Since I was working on both sides of the fence, I could easily move the logic from one to the other, sometimes changing my mind as I learned new information while implementing the functionality.

When working in larger teams, the work was usually split between hardware engineers and programmers. Occasionally I could influence a change in the hardware while working as a programmer, but not always. I really missed the ability to optimize across the hardware/software interface that I’d had when doing both sides.

When you scale up to large numbers of people working on a system, things can get out of hand, though. What happens when a lot of people make changes to the same components without talking with each other? Usually, the conceptual integrity goes out the window. So, what to do? Read More