An interview with James Grenning
Jack: The agile community says we often don't know what we want, so we wind up building the wrong things. That observation drives a lot of the agile practices. My experience with embedded systems is that we generally have a reasonably clear idea of the end-product, though some features and UI aspects might be fuzzy at first. But most embedded apps have no real UI, or a UI that is fixed as it consists of some LEDs and switches or other clearly-defined I/O.
I have observed that a large part of the fuzziness stems from poor requirements elicitation. Often that's because doing requirements analysis is no fun. TDD seems to favor downplaying the requirements phase. Instead, why don't we devote more effort to it?
James: The situation you mention is well suited for incremental product development; some things are clear, some are fuzzy. Design is a continuous process. Should requirements gathering and elaboration be continuous as well? When are the requirements really known? When are they done? The common answer I get to that question is "the day the product ships." Statements like that tell me that teams following a waterfall approach fall back to an evolutionary approach when things get tough.
In Agile, we consider that development engineering and requirements engineering proceed in parallel. Why delay development when there are important requirements, already known, that we could start developing? I don't know of a good reason for delay, but waiting has a definite downside. Serializing requirements and development adds unnecessary delay to overall product delivery timeline. You won't be able to get that time back that was wasted in delaying the start. Also, consider the time spent in a serial process, detailing out requirements only to cut them when you discover the date is in jeopardy. It's another waste you can avoid.
In agile, we strive to get good at evolving requirements and code concurrently. We want to get the product to market sooner. TDD says nothing about requirements collection. It is an incremental approach to development, which happens to work very well with incremental requirements gathering.
We will get some of the requirements wrong. This is the case for up-front requirements too. Development is invention; there is uncertainty. Building the product helps us figure out what we know and don't know, far better than more noodling over the illusive complete requirements.
One common concern I often hear is that some missing requirement will invalidate all our work. Sure it can happen if we started building a cell phone and in the end needed a washing machine. Requirements surprises are probably a greater risk for non-TDD projects. The TDD code base will be better able to handle a requirements mistake because of it resulting well-structured, modular code with automated tests.
One more thing on requirements, if you plan on staying in business, you better hope for new requirements; they are the opportunities that drive business. How many engineers out there are starting brand new products? I bet there are more of you working on ten-year-old code bases than the fresh greenfield product. Ask yourself, could you have defined the requirements that drive today's work ten years ago? Of course not. Today's requirements might not have even been known one year ago for some evolving products. TDD addresses the world that most developers find themselves in, a world where requirements and design must evolve.
Jack: Sure, but with embedded systems, we have to be pretty clear about requirements from the outset, as these impact the hardware design. That can't change much during the project since changes can drive the recurring manufacturing costs to the point where the product is no longer viable.
James: Are requirements really that clear? I bet some might argue with you. In the early stages, the hardware software boundary must be considered. Committing too early is a problem, too. Try to make boundary decisions reversible or finalize them when there is enough information. My main interest is the software side of this discussion, but there are people being more agile with hardware design. The X-15 rocket plane, completely a hardware project, was developed using incremental design techniques. There are some very agile hardware architectures evolving as well like the Cypress Programmable System on a Chip.
Loading comments... Write a comment