Slicing and Dicing Complex Projects...
In a recent post, Johanna Rothman asked the question, should agile teams Develop by Feature, Develop by Component, or Some Combination? Well, in a nutshell, my answer is, it depends.
I have seen teams try different approaches to this problem. And there is ample experience out there to draw upon. As Julian Sammy points out in his remarks, “My experience is that the feature and component layers have several many to many relationships, depending on the level of detail you’re working at...If you are building a new feature...then you should be able to factor this [into several components.]” Yep, a big feature needs to be broken down into smaller, bite-sized chunks. And sometimes, those components can stand in relative isolation from each other. But if you are basing a feature on a common domain model, you may want to develop in a way that feature code interacts with a common domain model. That’s how followers of domain driven design approaches tackle this problem. So that one way to split up the work...one group works on building up a “core” of domain objects that other components that comprise the feature use. And in more complex projects there are even more layers of complexity. Your code that implements a feature may need to interact with other systems and pre-existing components and services. And there may be parts of a system that have “upstream” and “downstream” relationships with your stuff. It can get all quite complictated. It can get hard to keep a clear picture of relations between things in your head.
So it isn’t always the case that a group of people developing a feature are in control of their own destiny (in fact, they often are relying on components or other systems developed by people who are working far away).
One thing that Bernd, another commenter points out, is that managing the dependencies between can get quite complicated. My experience matches up with Bernd’s. Even though you may have a timeline with expected deliveries between components, it still can be difficult to manage. No matter how well you specify an interface for what you need, it is always open to interpretation. Even with tests and exemplary code to illustrate what you want or what you are providing, the devil is in the details. That’s why people like to encourage developing code that exercises functionality that cuts across the systems and components you are trying to integrate. And if those systems or components aren’t ready yet, mocking is one way to get you ready to integrate. But still. It isn’t easy.
So while it is ideal to have control of a feature, on complex projects there will always be dependencies on other things that are not totally under your control. That’s what makes life so interesting, and the role of agile architecture and looking at what lies ahead while keeping yourself firmly planted in today’s realities so challenging. And if you are working in an agile world you take every opportunity to test out the difficult bits before you lock them down. That’s both a challenge and an opportunity.