The Myth of Software Reuse
I’ve had a suspicion for quite a long time that during my college years I had been fed quite a few untruths. The Waterfall Lifecycle would ensure requirements are defined before coding starts; everyone uses UML in the real world; girls would be impressed at your Java coding skills.
But of all those little white lies, perhaps the most heinous blot on most Computer Science graduates knowledge of the dark arts of programming is its most simple. Reusing code saves money.
This was touted as the maxim to know before going out into the real world. This is the concept that would save your future employers millions. Always reuse; seems simple enough.
However, after spending sixteen years in the depths of various software development projects I can say that most organisations simply do not lend themselves to the type of benefits that code reuse offers, mainly due to their team structure and organisation.
Product-Centred vs Library-Centred
Imagine two teams, Team A and Team B. Both require the parsing of some complex data. Wouldn’t it make sense to have a library to perform that action instead of both teams re-inventing the wheel?
The answer, broadly, is yes. Libraries are good. There’s lots of general purpose libraires out there that we, as developers, use every day. It makes zero sense to roll your own CI tool or ORM layer, when there are options out there that have been through the battles and have proven their worth.
So why should Team A and Team B not work on a library? Well, I’m going to make a few assumptions at this point. I’ll assume Team A and Team B both work for Company X, and they specialise in delivering value to specific customers. They deliver products to solve their customer needs, and Team A and Team B are working on two bespoke deliveries, for two different customers.
The simple, undeniable fact is that product-centred development is VERY different to library-centred development. In product-centred development, you have a single customer, and your goal is to solve a specific set of problems for that customer in order to provide value. In library-centred development, you have a specific problem, and you want to solve it in a very generic way, providing the most value to the largest group of users of that library.
That’s a subtle, but very important distinction. When you write generic code in library-centred development, you cannot allow the code to be driven solely by individual customer needs , because doing so might break the product for all other clients. However, in product-centred development, you are required to be driven by individual customer needs.
What does that mean for Teams A and B? Well they might both start out having the same requirements for their library. But as time goes on, maybe Team A requires some bespoke functionality to suit their customer. They put it into the library. Uh-oh. We may have just broken something for Team B. So let’s try and keep the library generic and each team can just use it as-is (open/closed principle). But hold on. Who is now responsible for the library? What if there’s a bug in it? Who will support it and maintain it? Will a product owner on Team A be happy at losing a developer for two days to fix a bug for Team B?
The real solution would be to have a “library” team, Team C. But we also know that in the real world we cannot afford those types of luxuries in a typical enterprise setting. Also, it’s questionable in an Agile setting if that team would make sense, as they would not be delivering a vertical slice of functionality to a customer within a sprint. (Of course, you could frame it that Teams A and B are the customers – would your company go for that idea?)
So what’s the answer?
Ideally, a company would invest in a core team that provides generic services and libraries for all teams in their respective domain, and these teams are library-centred as opposed to product-centred. This idea might even help with proper code reuse, and solve multiple problems for dependent teams. However, I’ve rarely seen this work, as the business do not see this team as adding real value (because they may not be directly working on features).
Another idea would be to make all code searchable across all teams. That way, while we may not be able to directly reuse the code, alot of the core concepts and ideas can be shared. Maybe that parser in Java could be ported over to a C# class, since the Java team has already figured out all of the regex that’s required.
The last option is every team write their own. This is really a horrible scenario, but unfortunately how we organise teams today seems to result in this type of siloed development. Until investment is made in that middle, library-centred approach to building teams, these are the only real options we have.
