I’ve been working with Rebecca Wirfs-Brock on an agile architecture workshop. I’m working with Rebecca because she has such a depth of experience in architecture, as well as design. She’s working with me because of my project and program management experience. We’re pretty psyched.
We’re working through the issues of large programs and architecture, and, of course, we have encountered the develop by component vs. develop by feature debate. I’m closer to the develop by feature side of the house than Rebecca. She’s a little closer to the develop by component side. We’re not too far apart–we’re not polar–we’re not precisely at the same place. And, we may never be at the same place, because our experiences are different. We each have good reasons.
You get tremendous benefits when you develop by component: high cohesion in the component and low coupling between components. Don’t underestimate the value of these. If you don’t pay attention to cohesion and coupling, eventually you can’t develop anything.
When you develop by feature, you get features. It’s hard to underestimate the value of working product.
But especially in a large system effort, with multiple teams, how do you do this right? Of course, it depends. You might have a combination of teams, in my preference after you have a little experience with some features. Maybe you develop some prototypes. Maybe you do something else.
We’re developing a simulation for the workshop. If you have encountered this problem in your system, please post a comment and let me know if you would like a simulation to explore this. (I am not under the impression this means you would commit to our workshop!) If you’d like to send me private email, that’s great too. We’re trying to develop a simulation that will mimic what happens at work.
