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.
November 3, 2009
There is saying that every speech is actually three speeches – the speech you planned to give, the one you gave, and the one you wish you gave. I think software development is very similar in spirit. Most software professionals want to produce high quality code. Yet,there is a difference between code that they write and what they wish they wrote.
There are a whole host of tactical code changes that creep into an application or product line which will have a negative impact for the long term. By tactical I mean short-sighted changes that corrupts the sanctity of the codebase – maybe it violates encapsulation, breaks the design principles that we meant to be followed, introduces needless coupling, worsens technical debt, and so on.
Why are these tactical changes being made? This question is extremely relevant to systematic reuse – whether you are pursuing reuse via objects, component based development, service orientation, or a combination of these. Here are some of my observations on why this happens:
- Time pressure – the need for meeting deadlines. Often senior developers are fully aware of the right place to add code yet proceed with tactical changes. If technical debt is consciously taken on, this isn’t too bad. But, are these always conscious decisions?
- Unwillingness to question key design assumptions (e.g. not considering ill effects of tight coupling between entities or systems) and not addressing support needs.
- Not considering the need to support multiple concurrent versions. Backward compatibility and client integration needs aren’t considered at development time.
- Lack of knowledge about existing capabilities in the codebase. It could also be inadequate knowledge about planned assets, or the roadmap for application transformation. This could be due to lack of communication and/or the developer being new to a team.
- Thinking about changes within the context of short-term deliverables only. This usually manifests itself in seemingly harmless code changes that mushroom into bigger problems later – adding a method in a convenient place rather than the appropriate one or cutting and pasting a variation of existing functionality.
- Lack of collective code ownership – if it isn’t my code or i didn’t write the first version why take the initiative to make it better?
- Inadequate knowledge of team’s coding and design standards and practices. Where should a new component be added? who will review the code to ensure that it is reusable? how do i let other developers know? how do i document assets?
Do these reasons resonate with your experience? What could be added to this list?
Like this post? Subscribe to RSS feed or get blog updates via email.