Art of Software Reuse GitBook

August 16, 2017

Very excited to share a new GitBook on Software Reuse – aims to provide a set of Practical techniques and strategies to succeed with software reuse. The book’s ideas will help you build reusable components, frameworks, services, and multi-tenant platforms.

Here it is and available for reading as well as for downloads:

Feedback and comments most welcome!

Building reusable Assets from existing applications

May 28, 2016

Although starting from scratch is simpler when building reusable assets, reality is that you are probably maintaining one or more legacy applications. Refactoring existing legacy assets has several benefits for the team. Here are a few:

  • The refactoring effort will make you more knowledgeable about what you already own
  • Will help you utilize these assets for making your systematic reuse strategy successful
  • Saves valuable time and effort with upfront domain analysis (of course this is assuming what you own is relevant to your present domain)
  • Make your legacy system less intimidating and more transparent.
  • Provides the opportunity to iteratively make the legacy assets consistent with your new code

If you cannot readily identify which legacy module or process is reusable you have two places to get help – your customer and your internal subject matter experts. Your customer can help you with clarifying the role of a legacy process. Likewise, your team probably has members who understand the legacy system and have deep knowledge of the domain. Both of them can guide your refactoring efforts.

The act of examining a legacy module or process also has several benefits. You can understand the asset’s place in the overall system. The existing quality of documentation around this asset and usage patterns can be understood as well. Now, you can make an informed opinion of the current state of what you have and how you want to change it. Before making any changes though it helps to consider the next few moves ahead of you. Ask a few questions:

  1. Is the capability only available in the legacy application and not in any other system that you active maintain and develop?
  2. Is it available only to a particular user group, channel, or geography?
  3. Is the capability critical to your business sponsor or customer? If so, are they happy with the existing behavior?
  4. How is the capability consumed currently? Is it invoked as a service or via a batch process?
  5. How decoupled is the legacy capability from other modules in the application?

These questions will help you get clarity on the role of the legacy asset, its place in the overall application, and a high level sense of the effort involved in refactoring it to suit your requirements

What I’m Reading & Learning

January 4, 2015

It has been a busy fortnight and have started reading a number of books:

…plus excited to take How to Learn: Powerful mental tools to help you master tough subjects via Coursera.

Think Hard About Conway’s Law

August 24, 2014

Was reading Adrian Cockcroft’s interview on InfoQ recently – where he talks about MicroServices and DevOps, and whole range of topics. A particular point about changing the team’s culture directly applies to reuse. 

I quote from one of his answers: “…is it Conways law?… what’s the organization…? Basically the law that says the communication structure of an organization will be reflected in the code. So you set up the … you decide what structure you want your code to have and you make the organization look like that;”

I am sure you have been in situations where you wish: the code for a reuse candidate was in a common shared source control repository, the components were adopting compatible technologies, that there was clear separation of concerns, and most important, there was a true culture of sharing and systematic reuse across projects. 

This is so true that it got me thinking – how often do we want something to happen – be it collaboration, co-creation, systematic reuse – and yet we run into organizational roadblocks? Lack of core competencies – too many people solving the same problem in a sub-standard fashion, conflicting priorities, inadequate knowledge sharing of not just code but more fundamentally: key requirements, lack of human / monetary / infrastructure resources, etc.

Instead of negotiating constantly across multiple teams – all looking to meet several success criteria – have you thought of organizing them by the outcomes you seek? If you want shared software assets, you need to foster sharing organically, through the organizational interactions that happen every single day. Who reports to who, who is held accountable for what, – the nuts and bolts of responsibility and accountability have to be thought through for the shared software assets you aspire to create and reuse. 

It’s easy to get a single flash in the pan reuse success story – it’s much harder to institutionalize it across teams and projects. Have you got the responsibilities in the team defined in terms of the shared software assets you envision? More often than not – we tend to look for magic bullets in terms of tools, technologies, trends, fads, and yet – systematic reuse is fundamentally about the delicate dance of interactions, trade-offs, and decisions that development teams have to make in the midst of competitive pressures and harsh deadlines. Focus on the form and structure and reuse will follow. If you aren’t getting reuse, think hard about Conway’s Law – the state of your software won’t lie – it won’t hesitate to show up the healthy or not so healthy nature of team interactions, incentives, and priorities that are alive and thrive on the ground. 


5 Questions To Increase Systematic Reuse Effectiveness

May 13, 2013

Here are five questions to ask your teams to increase reuse effectiveness when evaluating a functional requirement:

  1. Is a requirement already met within the application or platform or is this the first time?
  2. If the capability already exists, does the current implementation provide the right extensibility? Often, existing code would need refactoring to meet a slightly varying set of requirements when compared to the original one. Take this as an opportunity to tease apart the abstractions necessary to capture the variations. What’s common and what’s truly different is the key aspect to figure out.
  3. Which other team or application has encountered this functional requirement before and how did they solve it? If you aren’t sure, ask around!
  4. Do we truly believe we are the first ones to stumble upon this need in the team/department/division/the firm? Try “laddering up” – as the Heath brothers call it in their latest book Decisive – incrementally and deliberately extract the key aspects of the problem you are trying to solve and look for places where solutions already exist. 
  5. If you find existing code to meet your need – evaluate it with a critical eye towards non-functional needs. Is it performant enough to meet the needs of your use case? does it provide adequate extension points / hooks to integrate with the rest of your application? is it a library or a hosted service? If hosted, what is the resiliency and availability strategy?

Too often, there is a bias towards implementing from the ground up due to either lack of time (don’t want to find out if other implementations or existing solutions exist and if they do, would they fit) or lack of trust (don’t want to use this team’s software or codebase or don’t trust that the quality of the implementation).

These aren’t exhaustive – what other questions come to mind?

Surfing The Innovation Wave – Talk by Sharad Sharma

December 7, 2012

Heard a very interesting talk by Mr Sharad Sharma titled “Surfing The Innovation Waves” that puts in context the nature of innovation happening in the marketplace and the contextual forces behind the changes. He talks about adopting the
“hobbyist temperament” and gave several examples of people in the edges of industries disrupting the establishment. The key behavioral traits he mentioned are as follows:

  • Stepping outside one’s comfort zone
  • Having an internal compass – “i got to excel.” Don’t rely on external cues and rely on self-mastery instead.
  • Get comfortable to stand out and be an underdog.
  • Persisting in face of adversity. Even if you are right, it doesn’t matter till you are able to go past the criticisms that will keep coming

He then expanded on a New Age Code of Conduct  – keeping in line with the idea of the hobbyists and people who are innovating at the margins. He talked about volunteers, poeple are doing it for others like themselves and participating in creating and growing “Creation Nets”. The Creation Nets are going to be the wave of the future where many people sharing a common cause will come together and contribute to innovation via rapid and effective collaboration. Community activity is key because the world is much too complex and you have to collaborate with others for innovation to happen both within and outside the organizational boundaries.

This new code of conduct has particular behaviours that he recommends:

  • Setting others up for success. Form of servant leadership – make it your job to help others around you get to their goals. Evolving shared aspirations is very important
  • Make sure you give more than what you take – effect of the commons. Amplification of co-operation is key and if you don’t invest in public good, collaboration isn’t sustainable. Academic institutions take an active role to play in public good creation.
  • Say what you mean, do what you say. Allow for trust bonds to be formed – cannot allow duplicity. Without trust, no creation nets are possible and effective collaboration isn’t an option.
  • Make mistakes. Make them fast and recover quickly
  • Don’t wait for instructions – just make it happen. Pick the challenge that catches your fancy and start working to happen. Pull based model and not a push based model. I will do this with the best of my ability. Focus on excellence.

The talk is definitely worth the time in full – do see it online here:

Accelerating Reusable Component Adoption

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:

  1. Provide examples on how to wire the reusable component with widely used proprietary or external frameworks
  2. 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?
  3. 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
  4. 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
  5. 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.


Prefer Exploration Rather Than Perfection

July 1, 2012

In the zeal to create a reusable component, you should be careful not to over-engineer i.e. pursue perfection. The functional needs have to be at the core of the reusable asset’s ability to solve a particular problem. When in doubt, remember that as time goes on, the team will learn the nuances of the problem domain and will be able to make better design decisions. Explore the domain with the team rather than force a solution. How exactly do we do that? We can:

  • Practice creation of simple, domain-aligned abstractions
  • Continuously validate the domain with functional experts in the team
  • Consciously exclude aspects of the domain that aren’t relevant / well understood when defining reusable components

It is critical for the team to discover and stumble upon reusable assets – rather than big design up front efforts lasting for months. Keep it agile and continuously evolving and improving.

Client Integration Mini-Checklist for Services

May 27, 2012

Working with clients who are consuming your services? Here is a mini-checklist of questions to ask:

  1. While executing request/reply on the service interface is there a timeout value set on the call?
  2. Is there code/logic to handle SOAP Faults /system exceptions when invoking the service?
  3. Is building service header separated from the payload? This will facilitate reuse across services that share common header parameters
  4. If there are certain error codes that the calling code can handle, is there logic for each of them?
  5. Is the physical end point information (URL string for HTTP, Queue connection and name for MQ/EMS) stored in an external configuration file?
  6. Is UTF-8 encoding used while sending XML requests to the service i.e. by making use of platform-specific UTF encoding objects?
  7. If using form-encoding are unsafe characters such as ‘&’, ‘+’, ‘@’ escaped using appropriate %xx (hexadecimal) values?
  8. While processing the service response is the logic for parsing/processing SOAP and service-specific headers decoupled from processing the business data elements?
  9. Is the entire request/reply operation – invocation and response handling logic – encapsulated into its own class or method call?
  10. While performing testing, is the appropriate testing environment URL/queue manager being used?
  11. Is a valid correlation id being used in the service request? This is very essential for aynchronous request/reply over JMS (JMS Header) or HTTP (callback handler)

Role of Systematic Reuse in Enterprise Integration

January 7, 2012

Systematic reuse in the context of enterprise integration provides several benefits:

  • allows the team to evolve consistent set of data interfaces across integration efforts – if multiple systems need to integrate with yours, can you define a generic data model for your domain-specific concepts? This could be file layout(s), service interface schemas, or platform specific APIs
  • enables common interfaces for domain specific services and business processes
  • integration points often need cross-cutting concerns such as logging, transaction management, exception handling, etc. that can be reused
  • reusable utilities can help with support and testing tools – for instance,  reply failed messages, drain message queues/topics, generate high volume test data, etc.

Question is – are your teams taking advantage of integration points? or is each integration point implementing identical or similar functionality in an inconsistent fashion?

%d bloggers like this: