Discussions on reusability and reusable components are widespread among the practitioners of software engineering as well as the academia. A library of reusable components, one among the strategic engineering assets of any successful IT organisation contributes not only to productivity improvements but also to product quality throughout the life cycle of any software product.
Usability is one of the utmost qualities of any reusable component and any reusable component will succeed in serving its purpose only if the application or product that consumes it, is designed flexible enough to reap the advantages of reuse.
Think of a reusable component that can serve as a probe to measure the performance of any business application at run time on need basis. Its value becomes multifold when it can be used across multiple applications to derive performance parameters. While our expectation and imagination are endless, there are practical constraints that may not enable every software engineer to innovate reusability to such a larger extent.
In industries such as consumer electronics or civil engineering, the maturity level of reuse is higher as compared to that of software engineering. And, due to the inherent dynamics related to software engineering, such as changes in platforms, languages and tools, the life span of a reusable software component continues to be far less than the life span of an electrical or electronic component. Software components require frequent upgrades in order to comply with the new versions of platforms, languages and frameworks that they reside on. Despite this constraint however, identification and promotion of reusable software component has been one of the key focus areas of several organizations.
Several years ago I was leading the Software Reuse initiative of my team and we had setup a portal called ‘Reusability Centre’ that served as a central component library for the entire organisation. In those days, for any newly identified reusable component we used to ascertain if it was used more than once in the same product or project and we encouraged engineers to reuse such components and refine them before releasing them across projects. We also had a checklist to verify if a component is ready in all aspects to be a part of our library and had a set of senior technical leaders who used to handhold and coach young engineers in creating reusable components.
Creating reusable components that will be reused for sure by other projects is an uphill task and sometimes engineers need to map their components to real world scenarios. For instance, we do see products or application where a transaction (such as “approve vacation” in a Leave Management System) succeeds but, for some reason, the users do not receive a related email notification. When we troubleshoot such problems we get answers that indicate the failure of email server resulting in the loss of such emails forever. Clearly, the way to provide a solution to this problem is to create a reusable component that resembles a mail box and maintains a queue of such email requests so that emails are sent in case of all successful transactions.
In practice, the concept of reuse becomes very easy to implement at certain levels which include reuse of concepts, designs or templates. When it comes to code reuse however, developers may resist reuse and pursue the temptation to recreate. This does not necessarily mean that developers like to reinvent the wheel again and again but developers do utilise reusable components provided such components are practical and helpful.
Yes, Reusability does exist in many forms including component reuse. Typical examples of reusable components are Apache's FOP or Log4j in J2EE world – to name a few. This makes it evident that if we want our components to be reused, then we have to look into the usability aspects while designing, coding, testing, maintaining and releasing reusable components. Usability plays a critical role in creating usable systems and to create usable systems, we need to consider human abilities and limitations, learn about the needs of end users and involve them while designing such components.
How do we do this when we create reusable components? The answer, though not very simple, is two-fold. First the creator needs to understand the end-users, their needs and think like the end-users throughout the design process. Next, the creator needs to test the reusability of any component among peer groups or projects and enhance it so that it becomes reusable among a wide spectrum of users. For frequent reuse, the creator may have to provide the following artifacts in addition to the source code.
1. Feature list
2. Tips/instructions on usage
3. Sample code on how to plug-n-play
4. Contact info (Email/Phone) for help
Interestingly, usability evolves with the evolution of user experience on what is available and user expectation. The more our users understand and relate well to the systems they use, the better and faster they are in liking or disliking the systems we provide. Progressively, end users become more and more aware and demanding too. In the software industry for example, the more we get detached from users and usability the greater the chances of designing and delivering systems that fail to meet usability expectations.
Clearly, it is not enough to understand just the business requirements and technology to deliver software. The more we understand our users as well as the importance of usability, the greater our results will be in delivering usable systems. To conclude, if ‘Know Thyself’ is the mantra for happy living, ‘Know Your Users’ is the mantra for delivering successful systems.
The level of motivation and confidence in identifying, promoting and accepting reusable components is different at different ecosystems. Organizational culture, leadership commitment, team size, geographic spread and technical maturity are some of the key factors that make or break reusability related initiatives. At MindTree, we do have organizational initiatives to promote reuse and encourage communities of practices to specialize in component reuse. Also, our internal Knowledge Management portals encourage open exchange of ideas, problems, solution alternatives, etc. among us all. We see young engineers approaching us with brilliant ideas and we share our experiences with them and coach them in creating reusable components.
Software Engineers do spot reusable components in the code they produce. For them, the creation of successful components is a very challenging but an interesting journey. Noticeably, in case of electrical and electronic components users do get visualizations that provide answers to three key questions viz ‘What does it do?’, ‘How does it do?’, and ‘How can it be reused?’. For example a 9 volts DC adapter has visualization on its package as well as on its body to answer these questions. However software components do not have enough visualization even after several years of evolution. Visualization of reusable component is a way to add a new dimension to usability of reusable components.
On the other hand however, engineers who design applications or products need to promote reuse in terms of object oriented designs that are flexible enough to embrace reusable components.
Naturally, with usable reusable components – the providers, benefit several applications or products – the consumers, live long, add value and evolve.
About the Author:
Raja Bavani heads delivery for MindTree’s Software Product Engineering (SPE) group. He has more than 20 years of experience in the IT industry and has published papers at international conferences on topics related to Code Quality, Distributed Agile, Customer Value Management and Software Estimation. Raja did his masters degree in Electronics from Bharathidasan University and pursued a Post-Graduate Diploma in Computer Science and Applications.
I once had a class where they made great emphasis on the reuse of modules as part of a good defined architecture. However it was referring to hardware. Taking this to the software side must be good also. Actually I can already think of how to implement it on my company. A knowledge base portal focused on reusable code is a good process improvement idea. Though it crosses my mind that perhaps applying this to the firmware development might be a little more difficult since sometimes firmware tends to be monolithic… the smaller the device the more unique perhaps and as a consequence, it’s easier to have developers trying to author every little letter in their source code.
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.