Software reuse is very alluring – we can leverage common assets across products, improve quality, reduce development and testing time, and accelerate productivity for our teams. Sounds right and most of us in software want to do this.
A worthy goal? Yes, of course! An easy one? hell no! You must be thinking…yeah, right…the systems, services, and components i interact with resembles this…
Anyone who has spent time building software in an organization will tell you that achieving software reuse isextremely challenging. Large scale, systematic reuse is even harder in an organization. As a developer, I have always struggled with reuse – with deadlines to meet and functionality to deliver it was impossible to keep even code reuse in mind. Being a team lead made this predicament only worse – now I have to meet sponsor needs, deliver the features, and manage the development team to ensure we were on track with the project. Reuse, what reuse? forget about it!
Going through several projects and being part of very productive teams I have come to realize that software reuse is a indeed a viable idea. That isn’t to say it is easy but it is doable if we get some key things right. There are several ways to botch software reuse -that is the easy part! – but, I believe the following are essential for success:
Learn what your business stakeholders are trying to achieve – understand their vision, their priorities, and constraints and work on a reuse strategy aligned with that vision.
Work on several pilot projects, build steady momentum, and encourage word of mouth marketing for reuse. Never formally advertise _a deparment-wide or firm-wide reuse initiative – _this is a sure recipe for failure!
Realize that the common impediments to achieving large scale software reuse have nothing to do with technology
Put an extremely lightweight _process for ensuring projects leverage your firm’s _existing software assets
Collaborate, partner, and evangelize the benefits of reuse not just to developers – it is an _absolute must _to sell reuse to your management, business sponsors, and technical support staff as well
Understand the multiple levels of granularity with software assets. Software reuse isn’t only about cut-and-paste code reuse!
Build a network – this could be across distributed teams or within your department – of fellow _evangelists _who buy the vision, understand the challenges, the benefits, and most importantly will allow you to scale your success over time.
Now, none of this is straight forward. However, without these foundational building blocks it will be extremely difficult to achieve traction with software reuse. Many reuse initiatives fail to go beyond a single project, vaporizing without a trace. In the coming days, I will expand on each of these concepts.
What about your experience? How easy or difficult has it been for you to achieve reuse?
Your software development efforts don’t operate in a vacuum – they are sponsored by business stakeholders who have a vision or at the least a direction towards which they would like to proceed. As much as software reuse involves technical discipline and design excellence it is prudent to align with your business’ objectives. Before embarking on the systematic reuse journey – get at least high level answers to the following:
How is the business viewing their investments in your application till date? (ideally, they see a ton of value!)
Is the business strategy to drive growth organically or through acquisitions?
How often do the requirements change? what is the expected turnaround time for these changes?
What drives business to change, enhance functionality? is it regulatory? competitors? industry trends?
How does the business foresee the current business model – do they plan on radical changes? incremental changes? they don’t know?
All these questions at a high level will provide some sense of where your application is within the context of where your business sponsors want to go. Even if you don’t get much clarity it will help you realize your application’s business environment – may be you discover that it is a dynamic frequently changing environment or one that is steady and changes gradually. With this initial knowledge you can now focus on how to best create a reuse strategy. This is just the tip of the ice berg – the benefit of this exercise is that it will force both you and your business sponsor to really think about what the game plan is for a domain. This may show you that what you think is an application is really a product line. Or it could tell you that you are working on the wrong application. Either case, this will get you started!
People often ask me where is the opportunity for systematic reuse. I always tell them that in the enterprise software world there is a chasm between company wide systems for certain functions and individual application level code reuse. This chasm is filled with opportunities for systematic reuse. Between globally standardized application suites and ad-hoc cut and paste reuse lies several vertical domains where we can utilize systematic reuse concepts and techniques.
A business domain is likely being supported by several applications. The applications typically won’t share software assets and they might be at different levels of maturity with respect to enhancements, maintenance changes, support needs etc. Over time if not cared for, the IT environment will get more and more complex driving up the cost of ownership. Alongside this complexity will be harder to maintain code, multitude of processes, and a rat’s nest of applications talking to each other exchanging data.
These business domains are where I believe systematic reuse has most relevance. Systematic reuse can transform such a landscape into a product line, a family of related applications, sharing software assets that are domain relevant and not only fulfill business needs but provide the foundation to rapidly realize new ones.
Cut and paste reuse is simple and easy – so why not do just that? Because, it has significant disadvantages. For instance:
It increases codebase size. There is nothing eliminating duplication – so the codebase starts to contain multiple instances of similar logic. Systematic reuse aims to cut down the amount of incremental code that needs to be written to address new requirements.
Lose the benefits of enhancements and bugfixes: everytime you “fix” a problem with cut and paste code – that has to be propagated across the codebase. This isn’t trivial – every where the cut and paste code was originally placed, would now be coupled with various other classes.
Doesn’t promote consistency in behavior – cut and paste from one part of the codebase to another might save time in the short term but will quickly lead to different behaviors for achieving a capability. Over time, this increases the size and complexity of your solutions.
Makes it hard to refactor – when you refactor, there is extra care needed to make sure that new defects aren’t introduced and existing code is identified carefully. That being said, refactoring will help you reduce the amount of duplicate code and move towards a more reusable, more modular design.
Systematic reuse is a more deliberate and methodical approach to achieving high degree of reuse withreusable software assets. A_reusable software asset_is a piece of software that is of some value to your organization – that is the way I like to think about it (although much more formal definitions exist :-)) . Software assets could be libraries, frameworks, components, services, or business process workflows. In short, any unit of software that is or could be used across projects and initiatives for your organization. These assets are given a first-class citizen status with systematic reuse. These assets are managed like any other “product” – they are versioned, inventoried, governed, modified, and over time leveraged across multiple projects and initiatives. Additionally, there is a life-cycle put in place to take candidate assets – either from legacy systems or modules or from new ones – and evolve them into truly reusable assets. Systematic reuse also entails a maturity model where there is a road map put in place to transition from ad-hoc reuse – where assets might or might not get leveraged – to a high degree of deliberate, planned, reuse across several projects.
Systematic reuse has wide literature and there are several comprehensive approaches to it including Software Product Lines,Software Factories, and others. Here is the biggest mistake to avoid: don’t start building a reusable library of software assets right away!– it is recommended that one starts simple – very simple like a single project and with a focused group of candidate assets that could potentially evolve iteratively.
As the Chinese philosopher Lao-tsu said, “A journey of a thousand miles begins with a single step.”
There are many organizations – large and small – undertaking reuse initiatives. As much as the technical infrastructure, message processing, governance, and monitoring are important for your reuse efforts you cannot afford to ignore the organizational aspects. In this book, I want to not focus on your entire enterprise but your department or a group of development teams undertaking these initiatives. When aspiring for success you have to have more than developers and technical leads on your side.
So who else needs to be involved? You need your requirements analysts, your data modelers, and production support staff all singing the reuse tune albeit in their unique voices.
Many developers underestimate the impact of requirements analysts (also referred to as system analysts or business analysts). Some analysts mix requirements with design offering specific solutions to business needs. Requirement specifications end up becoming design documents. Why is this a limiting factor for systematic reuse? Because, you want to identity candidate services, reuse existing service capabilities, refactor legacy and modern assets and govern these service capabilities as part of your reuse strategy. Imagine, sifting through a requirements document that specifies implementing functionality as stored procedures or batch jobs. Without care, this can influence your thinking – knowingly or unknowingly binding you into solutions that are not in line with your reuse goals.
You want your requirements analysts to specify the business processes the application needs to automate, enhance and the business capabilities required. You can then deduce the business services, the enterprise data services, and the workflows that need to be developed. If your analysts are receptive you should persuade them to use a modeling tool that can specify an analysis model using a vendor neutral notation that can be imported into a workflow engine and converted into an execution flow. All said and done, the deeper point isn’t workflow orchestration or analysis model but about the_what_of the system. Using the what you can design the how. That is where systematic reuse comes in addressing questions around what services you will build, which ones you can integrate with, which ones to decommission, and which ones to change. Requirements should clarify and not prematurely solve technical problems.
Ask your analysts to provide world class requirements including functional and non-functional ones. Persude them to stay away from providing technical solutions so you can figure out how to automate your firm’s processes within the context of your reuse efforts. This isn’t easy and won’t be possible with every project but that shouldn’t prevent you from trying!