April 18, 2010
There is always an element of additional complexity when building resuable assets – whether it is because of externalizing configuration, adding additional interfaces/classes to provide flexibility, or introduction of additional layers of abstraction (to name a few). There is also the increased cost of design, testing, and integration with reusable assets. The question isn’t whether reusable assets are more or less complex – a more pragmatic question would be:
is the additional complexity absolutely essential and worth the cost?
This is a straightforward question to answer if you have visibility into what is coming up in the near future. If this isn’t the case – which is “most of the time” – the question becomes a trickier one. One way to address this issue is to introduce domain-relevant abstractions.
Instead of guessing what should and shouldn’t be an abstraction – work with domain experts and uncover true domain-relevant concepts. For example: Let’s say you decide to build a reusable library for providing customer data. Say this is used to populate a financial statement that shows a customer’s net worth (i.e. financial assets). Initially your software might have used the checking account balance to report this value. Why? Because, that was the only kind of account that was used to calculate this value. In the initial version the team might have thought ‘net worth’ was a data attribute – a number that is derived from the checking account balance. Over time, as domain understanding deepens, ‘net worth’ might become – not just a single account’s balance but a whole host of other things (e.g. accounts where the customer is a joint account holder including not only checking accounts but also savings, brokerage, etc.). ‘Net worth’ might still be a single number but it would have evolved to encompass a different meaning than just a single account’s balance. Not to mention business rules that have to be applied based on a plethora of account and client characteristics and quickly this would evolve into something more complex.
At the time of the initial release your team might not have this knowledge – and that is perfectly okay! Key is to evolve the codebase along with your increased understanding of the domain. Will net worth be it’s own class or interface in the initial version? If you don’t have even the preliminary understanding, why introduce needless complexity? wouldn’t it be better to refactor to reuse rather than build for reuse with an imperfect understanding?
November 1, 2009
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 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 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.
Have any of these signs resonate with your experiences? are there additional ones you can suggest?
Like this post? Subscribe to RSS feed or get blog updates via email.