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.
April 13, 2011
Wrote earlier about the importance of refactoring and continuous alignment within the context of systematic reuse effectiveness. Reducing technical debt is an integral aspect of refactoring. This post provides tips for reducing technical debt in your software assets:
- Minimize redundant definitions of key domain objects (i.e. competing, conflicting definitions of the same domain object across related applications)
- Minimize similar solutions for slightly varying business processes and instead create common process flows
- Loosen tightly coupled integration/transport logic with business logic
- Provide consistent strategies for implementing cross cutting concerns
- Replace tactical implementation for a problem that has a better open-source alternative
- Eliminate redundant approaches for managing configuration information
- Harmonize multiple, incompatible interfaces and make them more domain relevant
- Minimize excessive coupling with a particular technology/implementation stack
- last but not the least – create a comprehensive suite of automated tests
Are there similar themes in your development efforts? What steps are you taking to ensure technical debt is addressed?
April 16, 2010
Before you go organization-wide with the systematic reuse strategy it is surely worthwhile to get a pilot project (or multiple pilots even) going. The objective of the pilot is to test how well your reuse strategy can be applied to a real-world application. In a nutshell, here is what a pilot could be:
- Get engaged with 1 or 2 projects early in their lifecycle and identify reusable business and technical components based on their business needs. The key is identification – not necessarily implementation/realization. With the agile software reuse approach, we can refactor existing code to reuse or plan known assets as part of iterations on a as-needed basis.
- Identify folks from the pilot projects who are receptive to reuse and work with them closely. You want reuse evangelists, like-minded developers and technical leads who share the possibilities of reuse. It helps if they are also aware of the pitfalls and challenges with reuse.
- Collaborate with the project team to design new reusable components and integrate existing ones. Identify components that are : unique to an application, unique to a product line, unique to a domain, and relevant across multiple domains
- Prioritize assets from above list based on project constraints as well as business need. Implement a subset of these assets and examine how the integration works with multiple assets being utilized by a business process, service capability, or an application.
- Establish a environment for testing these reusable libraries outside the main application in order to facilitate reuse on subsequent projects. This is key for sustaining your future efforts – provide automated tests and an environment (a sandbox server to begin with will suffice) that allows developers to prototype using reusable assets.
Most likely, with a pilot you will learn a lot – a lot about how developers actually use reusable assets, what challenges come in the way in terms of project deadlines, lack of documentation, and unclear assumptions that the asset makes about the domain and even the operating environment. This exercise would also make it painfully obvious the technical debt various reusable assets are carrying – fixes, refactorings, and enhancements that are needed for reuse to be successful. This would be valuable feedback to use – work with your teams to flush out these issues and get to a working mode that allows for iterative and incremental delivery. Remember – your reusable asset doesn’t have to be perfect only constantly aligned to business needs.
October 6, 2009
Working with legacy assets can be difficult. You will start out with fear, uncertainty, and doubt (aka the FUD factor) and you will probably question if it is worth going through the trouble of touching old code. It might be tempting to just leave a legacy system alone and just write new code for what you need. Initial estimates for understanding and making code changes to legacy modules are likely to be gross underestimations. Good news – this won’t be the case forever. You will find that as you add regression tests and pay down technical debt in your legacy systems become the number one place you go for reusable assets. The inertia against making code changes will be high initially but over time this feeling will diminish. Your ability to refactor legacy code and analyze legacy processes improves over time.
You are doing right if…
- Your refactoring tasks are prioritized with the rest of your tasks for the iteration (maybe your coach or tech lead can help you with this).
- You identified the legacy asset changes, implemented them, and reviewed them iteratively. Getting the changes right with a legacy asset the first time isn’t realistic for most teams.
- Is there a single place to find all reusable assets? Is it accessible by all team members? If you have a geographically distributed team can they get to this?
- Do you have a plan for how this asset is going go be packaged, deployed, and consumed?
- Everyone in the team is aware of the new reusable asset and they know how to use it
- Every reusable legacy asset is either refactored fully or wrapped and consumed
Here are some warning signs to watch out for while building reusable assets from legacy systems:
- More time is spent documenting what is wrong with a legacy asset rather than coming up with the refactorings needed.
- It takes weeks for you to identify what the legacy asset does or what it is coupled with (hint: ask your team for help. You could be surprised how much undocumented knowledge is locked up!).
- The refactoring tasks are completely irrelevant to what your team is working on for the iteration (hint: the refactoring is either a waste of your time or your team isn’t communicating).
- The legacy asset changes are made without creating automated tests.
- The newly crested reusable asset has no documentation. No one knows what it really does.
Like this post? Subscribe to RSS feed or get blog updates via email.
: : : : :