Develop by Feature, Develop by Component, or Some Combination?

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.

5 Replies to “Develop by Feature, Develop by Component, or Some Combination?”

  1. Hi Johanna,
    being in the middle of a huge integration project (70 plants worldwide), we develop our core system based on agile scrum methdodolgy. The interface part is very complicated, since your associated applications out there (300+) aspect you to have a timeline for the drops and a list of interfaces. These stakeholders expect a schedule based delivery, but we work along the backlog. It is a mess. But if we would have done the traditional way, we would have rewritten the specs probably over a hundred times and would have had no output til today. So agile, rules, since you get something on the street drop by drop !

  2. 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. They may even be different names for the same thing, from different levels of detail. If you are building a new feature like “Customer transfers money” then you should be able to factor this into components like “system authenticates customer”, “customer withdraws money from source account” and “customer deposits money into target account”. (I know this isn’t how transfers really work, but it’s illustrative.) in this scenario, some components — authentication for example — may already exist, and can be reused. For components that don’t exist, well, have the team define them for possible reuse. Record them to a reference architecture, and make “check reference architecture for reusable components” a mandatory step in your development life cycle.

    But what if “Customer transfers money” could be considered a component of a bigger feature, like a sales transaction? Now what? I see two options. One way – I call it relativistic- is to build a conceptual architecture like a mind map, showing relationships like “[Feature] is built from [components]” and “[Component] is part of [Features]”. You will need to educate stakeholders on the relationship between features and components, and maintain the map, of course.
    Another way is absolute: staring with either “component” or “feature”, define this functionality at an arbitrary level of detail. If you start with components, then a feature is a collection of components. In this model, features can not be a collection of features – you need a different name for that level of detail, like a “scenario” or “feature set”.

    I am a fan of the relativistic approach in most circumstances, because it let’s the team be more flexible.

  3. Johanna,

    I’m curious about your simulation, not committing to anything, of course…

    I’m also interested in your take on an approach to this problem. It seems to me that you need to understand the type of system that you are building (and the features contained in the backlog), along with some form of high-level design to get you there. In your experience, is the answer one of starting with a documented design (based on what you know now) and then implementing the features as dictated by the backlog prioritization? (Features likely making use of one or more components.)

    This forces you to think about the architecture and components up front, but gives you the advantage of implementing only what you need to support the specific priorities in each iteration. As long as you don’t remain wedded to the initial architecture laid out on paper, this should enable an “emergent design” as the real-world system evolves that won’t get you into trouble because you’ve at least done some thinking and planning up front.

  4. You say, “You get tremendous benefits when you develop by component: high cohesion in the component and low coupling between components.”

    Well, sometimes. It depends on who is developing the component. I’ve seen component developers who generated very low cohesion, because they added whatever functionality was needed in their component, because that was the component they were coding.

    In my experience, it’s best to develop by feature, but with a high awareness of the components and their responsibilities. I have no doubt that when Rebecca Wirfs-Brock develops by feature, she ends up with good high-cohesion low-coupling code.

  5. I would be very curious on best practices surrounding a large, agile project that has a need for incremental enterprise system changes to match up with a subset of stories. An example in my mind would be along the lines of:

    100 stories across 10 iterations with with 5 stories requiring 5 different enterprise/legacy systems to make incremental changes to support the completion of a corresponding story.

    The extra catch is that the resources making those enterprise/legacy changes are not part of the core agile team and have their own, separate systems analyst and developer integration resource model.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.