Reuse Creates Bottlenecks
Here is something to think about. Is re-use always good? Is it always a good idea to have shared services and rely on common components? I jotted down a great quote at Oredev this week but can’t seem to recall who said it. “Reuse Creates Bottlenecks”. Isn’t that what we have really been talking about over the past few weeks? When you have a team… or a department… or a division… or a business unit that has everything it needs to deliver… it sure does make planning easier. Why? Because you reduce dependencies on the rest of the organization. There is less coordination… there are less constraints.
But is that how we tend to think most of the time? We seem to think that we’ll pull out all the stuff that is common and share it across the enterprise. That might make sense… it might be the best use of our resources… but it might create unnecessary dependencies that we’re going to have to manage for the life of the product. So here is a word of caution… if you are going to move toward shared services, have you considered the impact that decision will have on your ability to be responsive to your external customers? Have you considered what you are optimizing for?
Organizations that have people in functional silos are, in a sense, reusing people. They believe that having folks with similar abilities working for the same manager is the best way to optimize their limited resources, to get the most out of their investment dollar. Agile teams know that optimizing for throughput is better and tend to rely more on specializing generalists to level variations in the need for talent over time. Reusing system components has a similar effect on the organization as resource silos… and leads to the same kind of behavior. More documentation… more up front planning… and more managing dependencies.
So… if reuse is essential… or strategic… go for it. Just understand your trade-offs. If you are doing it because you think it is going to lower costs… you might want to think about it. If you trade shared systems for increased coordination and management overhead… you might not save as much as you think. Anyway… something to think about.
Comments (4)
Mike Bria
Good thoughts, Mike.
I think that re-use of code/components is good. Correlating a component to a single person (or team) is where things go awry.
As you say: "Organizations that have people in functional silos are, in a sense, reusing people." That's correct.
This is where Collective Code Ownership is key. Just because there is only one shared component that handles logging responsibilities, does not…should not have to mean there is a "logging" team. Everyone should be responsible and capable of making changes in there if need be.
Maybe we're saying the same thing?
Cheers
MB
ps// hope all's well with Pillar!
Mike Cottmeyer
We are saying the same thing, but it is a matter of scale. My experience is with large, large projects with large scale system components where shared code ownership across the entire stack isn't really going to happen. These 'components' are really systems in and of themselves that just happen to be integrated into a large integrated product.
So… there is a line. At some scale I am an advocate for shared code ownership, total test coverage, and one team making any and all changes. There is some level of scale where this has to be broken apart (in my opinion). In those circumstances, shared components will create a bottleneck. No value judgment here, just something to be aware of.
jeremie.chassaing
I made a distinction between code that can be reused and code that should be simply used (as a followup to a post by Udi Dahan)
http://thinkbeforecoding.com/post/2009/07/24/DDD-and-Code-ReUse
Craig Brown
The question is about capability.
What is your organisaton's capability?
Is it ready for the cost/benefit trade offs? Is it even able to capitalise on the ptential benefits.
Sadly too many organsations are overly optimistics, and waste millions on potential that is never realised.