In the hectic routines of projects and deadlines it is easy to ignore reuse. After all, we are delivering code, features, and churning out applications - aren't we? May be you are waiting for the right time to start and execute on a reuse strategy. May be you think software reuse is a big myth and isn't worth pursuing. Regardless of reason poor design will eventually inhibit your efforts to more more agile and responsive to business needs. Here are ten tell-tale signs that your team needs systematic reuse:
- Management believes they can install or buy reuse. You are told reuse comes for "free" with OOPS, SOA, BPM, MDM, (you can add your favorite buzzwords here!). Nothing could be farther from the truth :-)
- There is no management support for reuse. You typically hear some variation of deliver, execute, and just hit the deadline. What should be a small change rapidly mushrooms into something that touches several classes or services and forces you to change code across modules. To boot, this happens often. This of course adds technical debt and will hurt the team in the long term.
- Developers love to build their custom implementations for which satisfactory solutions exist. It could exist in-house, in the open source community, or available commercially. We have all met the developer who wants to build a better logger than Log4J or a better dependency injection container than Spring. Whatever. The argument usually goes this way: we have special requirements that no one else has and we have the best talent to build it (maintenance, ongoing bugfixes, support costs are conveniently excluded).
- No scope for reuse in the problem domain. Nothing can be considered for reuse you are told. Our domain is so unique that it changes often - nothing is common across projects or initiatives and we need to keep churning out code to meet business needs. This might be true to an extent but but not the way it is portrayed.
- Your developers and technical leads tell you that their software assets are perfect - they have been made completely reusable for all future needs. Be very wary! Predicting the future is tricky and systematic reuse isn't going to guarantee perfection. More importantly, your investment in reuse is going to provide you the foundation to turn out new features and business processes quicker but doesn't eliminate the need for continuous evolution of those reusable capabilities.
- There are several different versions of a common need like getting customer data or getting a database connection. Each with its own set of assumptions about data structure, error handling, etc. You know there is an opportunity to create a common capability but developers find it easy to cut and paste code from one project or component into another.
- Each developer implements capabilities without the faintest idea of existing ones. You find duplication sprinkled liberally across your codebase - all trying to do the same thing in multiple ways. Each developer of course believes that they were the first ones to implement it (and implement it right!!).
- Design is an after-thought you are told. Why waste time in design when you can implement? No, you don't want big design up front - and you also don't want the opposite. This sign usually manifests itself during testing - you discover the same need across sub-systems or modules. A little design would have discovered this as a reusable capability early on.
- There is no investment in training, documentation, communication, or integration support for reusable assets. If you build it they won't come and you end up with a library of assets that are buggy, unusable, and worse - irrelevant to business needs.
- You have no hooks in the development process that will help you proactively take advantage of reuse opportunities. Reuse if any happens ad-hoc due to heroic efforts of one or two developers sporadically.
I agree with most of your points, but I do want to take issue with the first one. If you use a BPM based on BPEL you really do get reuse "for free", since the language is built around services. Every step that does significant work within a process and every capability that is provided by the process is used/provided via services based on WSDL. What is also important is that this architectural benefit comes at almost no cost when you have good tooling that actually makes it as easy or easier to create a service-based application using BPEL than it would be to create the application using a technology that treats services as an afterthought, or worse, intertwines business and presentation logic.
Mike
I see where you are coming from and agree with your points. Some technologies and tools do make it easier and facilitate reuse (like you have pointed out). My intent with point #1 was to convey that a particular technology all by itself isn't going to guarantee widespread systematic reuse. There are several other issues that are involved (for instance architecture/design, governance, production support, training, ownership/organizational, and budgeting issues).