July 6, 2014
Here are a few quick tips to examine your existing code to identify reuse candidates:
- Introduce Factory or Builder instead of repetitive boiler-plate code when constructing key objects. Several benefits: makes it easy to refactor and evolve how underlying objects are stitched together, makes it easy to write more intention revealing code, and very relevant / convenient when writing automated tests
- Clarify functional behavior and tease out non-functional logic – look at how functional logic is implemented across your codebase. Do multiple projects share a common set of domain assets – objects, rules, services, and the like? if not, look for areas where functional logic is tightly bound to non-functional aspects like fine-grained metrics capture, exception handling, retry / timeout handling, etc.
- Public API that needs to be accessed across platforms / devices are strong reuse candidates – for instance, are there functional APIs that don’t have a remote interface (e.g. a plain Java implementation without an appropriate REST-ful web service resource)? Do you need functionality to be made available across multiple devices with varying User Interface semantics? If so, look to carve the shared logic out into a service that can be accessed from multiple devices / integration points
July 21, 2013
There are certain key interception points during the development process that can greatly increase the likelihood of systematic reuse. Some agile practices can really help:
- Estimating User Stories – constantly seek synergies and ways to connect new requirements with existing ones or those from other projects the team is working on. You know you are successful when the most junior member of the team is finding commonalities and points out areas to explore for systematic reuse. Very often however, reality is starkly different – similar, slightly varying functionality gets implemented over and over again across projects due to time constraints, lack of awareness, and implementation considerations – e.g. legacy system won’t be able to use this component” or “the existing system implementation is hard to refactor…”, etc
- Pair programming – the real strength with pairing is the variety in perspectives. One person can go for depth (identify a very efficient algorithm) and another can focus on breadth (identify existing components to reuse/extend or contribute current work). It is also convenient when pairing to switch perspectives and identify ways to improve the code by eliminating what is not necessary. Hard to expect one developer to be your systematic reuse superstar every time across every project.
- Code reviews – this is a rich area for reuse opportunities because of two key reasons – one, the idea is proven – it is in code and executing – not just vaporware. Equally important, it is a chance to re-look at the implementation with a detached perspective. Discover unspoken design assumptions, needless couplings, and free up code to be more extensible. Look for unnecessary 3rd party library dependencies, code quality violations that compromise layering (presentation code invoking database or data access logic having UI formatting logic, etc.), and constantly eliminate duplicate boiler-plate code. Remember – continuous alignment and not perfection is the intent here.
- Retrospective – when discussing what went well and what needs to improve – explicitly invest in learning the team’s challenges with systematic reuse. Listen for key signals from the dev team – do they have access to source code? how easy or difficult is the existing component library? what functional goal can be achieved faster if there was further investment in a reusable component?
June 16, 2013
It is natural to get comfortable, perhaps too comfortable, with the state of your codebase. After all, it works and is probably meeting tangible business needs. However, if your team has to get the full value out of it – the fair and ongoing return on investment – you have to constantly revisit assumptions about the software design and implementation.
Challenging assumptions has a number of benefits for systematic reuse. It opens up opportunities for refactoring assumptions that are no longer relevant / required (e.g. state information has to be saved for recovery). What if that capability is available in your enterprise through another component? Can you swap your implementation? If not, why not?
Similar opportunities exist on both technical and functional sides – the software is always accessed from the app’s web UI (assumption that might have led to code tightly coupled with presentation logic – business rules implemented alongside HTTP header parsing logic). How about assumptions regarding public APIs, nature/sequence of method invocations, client / calling platform, etc.
These assumptions must have made sense and would have been made for a sound reason at the time the codebase was conceived. Question is – are they still relevant? does the code need refactoring to get rid of native implementations or needs to be decoupled from logic that will make it more reusable? All these questions need careful and thoughtful consideration.
Have this discussion as part of your iteration retrospectives, team discussions, and informal conversations. You’ll be surprised about the quantity and quality of assumptions that are holding the codebase back.
March 24, 2013
Refactoring is a way to improve code quality over time using incremental set of improvements – the idea is to increase the ability to make changes safer and faster and is not meant to deliver new functionality per se. For systematic reuse to succeed, refactoring has to happen often and on a continuous basis. Why? It provides several benefits from a systematic reuse perspective. For instance:
- You will learn which aspects of the code base have the most technical debt – what’s complicated to understand and extend/enhance? which parts of the codebase are difficult to verify via automated tests?
- See repetition more often and will eliminate redundant methods, classes, even entire chunks of functionality – over time, you will see the same capability being provided by a different library, or there is a new requirement in a project that can reuse the capability if changes were made to it etc. Finally – and this happens to me a lot – you ask yourself – “what was I thinking implementing it a certain way when there is a better approach?”
- Systematic reuse needs deep understanding of the domain – the team needs to tease apart different technical concerns, identify which ones are relevant for the business, and identify variations within the scope of candidate reusable components. Which brings us to the most important question – are the assumptions made earlier about the domain and the subsequent design still valid? This continuous validation and re-validation of the core underlying assumptions and design choices will ultimately decide the reuse effectiveness of the component
- Over time, doing this will provide the team with a valuable data on providing estimates – which parts of the codebase are tricky? which ones lack tests? which ones are bug infested? All these aspects weigh into an estimate and continuous refactoring will give the team very good insights.
So, please don’t wait for a project or a deliverable to arrive – start refactoring every day and across every project 🙂
August 23, 2012
Many teams want to incrementally build a portfolio of reusable components so multiple projects can leverage them. This post will provide a list of potential areas to look for achieving systematic reuse – chances are that you have a few components in these areas already. Assembling them into a standard set and making it available for easy consumption will dramatically increase adoption rates across projects. Here are the areas to invest and/or harvest existing code:
- Configuration – specifically properties that vary across environments (e.g. DEV, QA, PROD). How are teams defining and managing this information today? If you are using Maven, teams may be employing multiple strategies – profiles, assemblies, custom scripts, naming conventions, etc. Why not consolidate practices?
- Transformation APIs – many projects require data transformation between objects to JSON or objects to XML and vice versa. Teams might be using different transformation libraries, may be wiring them with Spring or other dependency injection frameworks in a bespoke manner. Why not adopt a consistent API that provides transformations via a common set of classes with pluggable format-specific providers?
- Flexible Query Construction – lookup methods that require one or more parameters will end up having common boiler plate code that binds parameters using boolean conditions – why not provide a reusable API that allows the developer to wire parameters using a common API?
- Integration with internal and/or external systems – retrying, alerting, message construction, metrics, and proactive monitoring are all cross cutting concerns that are common across projects. Teams must be realizing these capabilities using multiple APIs, injection hooks, and response loops – again a consistent and reusable API will not only cut development costs but also make application support simpler
Existing code and components do however carry several risks that have to be addressed to realize reuse potential. For example:
- How domain agnostic are the components? Does it have a well defined interface and ability to adapt to a family of use cases?
- What is the learning curve for developer adoption? Does it have well defined adoption patterns that are easy to learn and intuitive?
- How testable is the component? Does it have interfaces that capture and model varying behavior ?
- What is the support model for the component? How to submit bug fix or enhancement requests? is there enough expertise in the developer community?
- What will be the release cycle for reusable components ? This becomes critical as more projects start to leverage a common suite of components for a varying set of capabilities
August 11, 2012
When building reusable components, you want to allow rapid component discovery, assembly, and testability. Without these characteristics, it will become difficult for developers to use the reusable components in a productive manner. Below are five things to do to accelerate component adoption:
- Provide examples on how to wire the reusable component with widely used proprietary or external frameworks
- Make it easy to use sensible defaults with frequently used features – if almost every application needs a particular feature, why not make it the default option?
- Open up the source code and invite feedback and improvements – chances are high that your development community has tons of ideas to make use of reusable component in new and innovative ways
- Engage early in the development lifecycle – don’t want till the very end to evangelize / educate teams about the component – actively and continuously engage with the developers to look for integration opportunities
- Tie code review feedback to component adoption – spotting code that has traits such as duplication, inefficiency, unmaintainable? Treat every defect as an opportunity to remove technical debt and increase consistency
These are by no means exhaustive and key is in performing them in a disciplined manner project after project.
December 26, 2011
One common criticism against systematic software reuse is the myth that it implies perfection – creating a reusable asset automatically conjures up visions of a perfect design, something that is done once and done right. Many developers and managers confuse reusability with design purity. However, reusability is a quality attribute like maintainability, scalability, or availability in a software solution. It isn’t necessary or advisable to pursue a generic design approach or what one believes is highly reusable without the right context.
The key is to go back to the basics of good design: identify what varies and encapsulate it.
The myth that you can somehow create this masterpiece that is infinitely reusable and should never be touched is just that – it is a myth and is divorced from reality. Reusable doesn’t imply:
- that you invest a lot in big up front design effort
- you account for everything that will vary in the design – the critical factor is to understand the domain – well enough, deep enough, so you can identify the sub-set of variability that truly matters
In the same vein, reusablility strives for separating concerns that should be kept distinct. Ask repeatedly:
- Are there multiple integration points accessing the core domain logic?
- Is there a requirement to support more than one client and if so, how will multiple clients use the same interface?
- What interfaces do your consumers need? is there a need to support more than one?
- What are the common input parameters and what are those that vary across the consumer base?
These are the key questions that will lead the designer to anticipate the appropriate places where reuse is likely to happen. Finally, it is important that we don’t build for unknown needs in the future – so the asset is likely to solve a particular problem, solve it well, solve it for more than one or two consumers, and finally has potential to be used beyond the original intent. At each step there are design decisions made, discarded, continuous refactoring, refinements to the domain model – if not re-definition altogether.
Don’t set out trying to get to the end state or you will run the risk of adding needless complexity and significant schedule risk.