Sponsored Link •
Bill Venners: In your book you write, "Whatever the structure of your architecture, build it in spikes—that is, user-visible functionality driven through all layers or subsystems." Could you explain what "build in spikes" means?
Luke Hohmann: Any architecture that I've ever been associated with, whether it had three tiers or 38 tiers, had some concept of layering or subsystems. There are very few architectures that are just one blob of massive crap. There is usually some concept of subsystems somewhere. Bear in mind that 95% of my career has been building business systems. I'm not the guy building embedded devices. I'm not the guy building the Space Shuttle control software. I'm the guy who predominantly has a user interface, a service-oriented interface, domain model, some mapping layer, and persistent data. There's some stack there.
The way I like to envision adding functionality to a system is "spiking the architecture." The way to do it, in my opinion, is to take one use case and push it all the way through. This is what all the agile methods say, and I call that a spike. Other people call it other things. The reason I call it a spike is that I think it is equivalent, in terms of effort half the time, of lining up five boards, putting a spike in, and trying to drive it through. It's tough sometimes to get it all to work out.
Spiking the architecture contrasts with building one layer at a time. You read about it and you think, people don't do this—yeah, they do. I've seen teams do it. They build a whole layer, build the whole flat layer, and then try to put the next layer on, and the next layer. They find out they don't work, and they have to go way back to the beginning and redo it. After the first release in one of my development organizations, I gave the team a bronze railroad spike as part of their prize for the release.
Bill Venners: The Pragmatic Programmers, Dave Thomas and Andy Hunt, talk about firing "tracer bullets." If there's an area of risk, you fire a tracer bullet all the way through the architecture just to make sure your concepts will work, and you learn things by doing that. In your spike metaphor, you're talking about how to implement each feature. If you need to implement three features, you don't support all three in one layer, then all three in the next layer. You implement one feature through all layers, then implement the next feature through all layers.
Luke Hohmann: Well, Dave and Andy are great guys, and their description of tracer bullets matches nicely with my own description of spiking. The concept isn't terribly new, and different people or groups call it different things. Extreme Programming, for example, would say that you take one user story and drive it through to business value. The benefit of that is that it's controllable and riskable. By "controllable," I mean you can limit the scope to make certain you're pushing something through. By "riskable", I mean that you can determine the level of risk associated with the spike. Simplifying keeps it under control and helps manage risk.
Unfortunately, most approaches to building in spikes (or tracer bullets, or stories, or use cases, or whatever) have a big weakness: They don't provide much advice on how to really structure the sequence of spikes or delivery of functionality. I've got seven user stories—why should this one be first?
Figuring that out order is the role of a product manager. A good product manager will say, "You should do this one first, because the market will pay the most for this one. It's the most valuable in the market. If we do this one first and this one second, we get a leg up on our competition." People say, "The business people are supposed to tell me what they want done, and I figure out how." I say, "Yeah, that's right, but that's not enough. They should also give you insights on the ordering, because ordering is a business decision." And the way I marry that is that I require business people give me an ordinal ranking of the features (this is number 1, this is number 2, and so on) along with what I call the the "cut line"—the minimal set of features that are needed in the release to be considered successful along with an ideal release target window. Before I actually agree to the final set of deliverables, the development team does a dependency pass. The business person may say that this feature is the third on her list, but based on a technical dependency analysis, that feature actually has to be done first. And usually you have at least two passes at that.
So it's not just saying to the business person, "Tell me what your user stories are and rank them." It is, "Tell me what your user stories are, rank them, let me come back with a pass through them from a dependency perspective, and then we'll negotiate the cut line or the release set." The release set has to have the minimum set of features that you can go to market with and be successful, plus the set of dependencies that make that whole and complete, as opposed to immature. Oh, one last thing. The features have to be ordinally ranked—not a group of "five important things" but, quite literally, "this is number one, this is number two".
Come back Monday, March 22 for the next installment of this conversation with Luke Hohmann. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.
Luke Hohmann is author of Beyond Software Architecture: Creating and Sustaining Winning Solutions, which
is available on Amazon.com at:
Luke Hohmann is the author of Journey of the Software Professional: The Sociology of Software Development, which
is available on Amazon.com at:
The Pragmatic Programmer's home page:
A good place to start looking into Extreme Programming is: