Software Reuse Quick Tip #3

March 30, 2009

Tip #3 Never release a reusable software asset without a suite of automated regression tests

If you are going to bet on a reusable software asset and advertise it to the world you need to have a suite of regression tests for it. Why? without regression tests, current and potential consumers will not have adequate confidence in the asset. The very foundation of reuse is to get a higher quality – less opportunity for errors, bugs, incorrect implementation of requirements – from not having to produce something that is already exists. To make sure you can deliver on this promise, a comprehensive suite of automated regression tests is a must. It will not only help you for your immediate consumer but for everyone thereafter.

Like this post? Subscribe to RSS feed or get blog updates via email.


Wrap legacy software assets

March 29, 2009

Your enterprise probably has legacy software assets that are extremely valuable and can be the basis for your initial project deliverable. If you don’t take care and start reusing straight away you will end up with lots of point to point connections…

legacy_asset_reuseNow, all the consumers are directly consuming your legacy asset with all the ill effects of tight coupling. You want to change or upgrade the legacy asset? it might break every consumer and force them to make changes to their code. Plus, you will expose your legacy error codes, naming conventions, behaviors to all your consumers.

Bad idea. So what do you do? Don’t reuse legacy software assets as-is; wrap them first!

Create a component that wraps the legacy asset – it now sits in be the legacy asset and the consuming code (which could be your app, an external process, a batch job, whatever…). This wrapper component needs to provide a contract that is in alignintment your enterprise’s data standards, should reuse your enteprise’s data types, use standard error codes, and most importantly should not expose legacy naming and/or implementation semantics.

wrap_legacy_asset_reuse

Why this is important? Well, if you don’t have a wrapper that truly encapsulates the legacy functionality it will serve only as a pass-through layer adding no value. The wrapped asset now can be reused by multiple consumers and you have the flexibility to change the implementation.  If you keep your interface constant, your consumers won’t need a code change and only need to regression test.

Like this post? Subscribe to RSS feed or get blog updates via email.


Not sure if something is reusable? Delay the decision…

March 27, 2009

The really interesting problems in your domain will require considerable thought, collaboration with project stakeholders, multiple iterations, and real end user feedback. This is the prime real estate for systematic reuse to thrive. However, just because something seems reusable, it may not be…at least, not yet.

Consider these questions….

uncertain1Is a piece of functionality really reusable beyond the immediate project?
Will making something reusable add significant change to the existing design?
Is the relevant problem domain for the functionality being understood?
how will this functionality evolve over time?

When you have more questions than answers about a potential reusable asset – resist the urge to generalize, add layers of abstraction or product variability. Instead, focus on the immediate business requirement and fulfill just that for your immediate iteration or release. Mark the idea or functionality as a reuse candidate but don’t necessarily make it resuable yet precisely because you may not know what you don’t know.

Kevlin Henney, in an entry in the book, 97 Things Every Software Architect Should Know refers to the this concept calling for ‘Simplicity Before Generality, Use Before Reuse.’ (This book is a must-read by the way – a superb collection.)

Remember, the additional domain clarity over the life of the project combined with real user feedback will help not hurt your cause.

Like this post? Subscribe to RSS feed or get blog updates via email.


Good design is at the heart of achieving systematic reuse

March 26, 2009

Good software design will help achieve your systematic reuse objectives. It is critical for achieving several things:

Identifying candidate or potential reusable software assets

Reducing coupling between software modules, systems, services, and processes

Ensuring that a reusable software asset can scale and perform based on your neeeds

Gracefully extend a software asset’s capabilities to meet changing business requirements

….and many more related to supportability, availability, testing effort, etc.

Design is at the very heart of systematic reuse – without good design practices and principles your reuse effort will not succeed. Good design is a necessary (not a sufficient) condition for success.There is a ton to be said on this topic and we will certainly explore them using examples.

In your experience, has design facilitated a reuse initiative or effort? did good design help achieve high degree of reuse for a service or component?

Like this post? Subscribe to RSS feed or get blog updates via email.


Software Reuse Quick Tip #2

March 26, 2009

Tip #2 Name your software assets appropriately

Whether you are naming a method, a class, a component, a library, or a service – pause a minute to really think about the software’s purpose and capabilities in order to assign a name.

An appropriate name will help you when trying to mine for existing software assets to be reused. Additionally, the effort will be fruitful when you are trying to refactor existing software assets to be more reusable.

Whenever you come across a method like doEverything() or a service SendDataToXYZSystemService – take a minute to rename them appropriately. Too often, a bad name will cause that extra bit of research for you to evaluate a capability that exists in your applications. If the name is too obtuse, you might not recognize functionality that is already there and build a duplicate one.

Good names are obviously tied to your problem domain but general guidelines still are valid – it is a good idea to name software assets based on the business functionality or capability. If you are publishing order updates to another system, why not call the asset PublishOrderUpdates instead of SendDataToABCSystem?

When you name an asset in a simple, clear, and accurate manner you will be surpirsed how often it will help you reuse it.

Like this post? Subscribe to RSS feed or get blog updates via email.


Where is the opportunity for systematic reuse?

March 25, 2009

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.

Like this post? Subscribe to RSS feed or get blog updates via email.


Aligning reuse with the business vision

March 25, 2009

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 knoweldge 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!

Like this post? Subscribe to RSS feed or get blog updates via email.


%d bloggers like this: