Several months ago one of my team members had identified a reusable component from his code and wanted to release it to his colleagues. When he approached me with his idea, I asked him ’Have you used this component in different contexts and found it reusable?'. He responded with a firm 'Yes'. I ticked the first checklist item to qualify his component as 'reusable'. There started his uphill task of publishing it and getting acceptance from our local community of Software Engineers. He stretched himself to make it happen. That was indeed an uphill task!
Last week I was in a meeting with my engineers where all of us delved into a discussion on reusable components. Our conversation emerged with a flavor of belief that the reuse of concepts, designs and templates are easy to implement and it is very hard to develop and release reusable components that other developers can use to avoid reinventing the wheel. Our conversation openly claimed that developers do not like to use a component developed by others and would rather develop their own.
Eventually, after several minutes of debate we settled together with the fact that developers do utilize reusable components. 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, 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. 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. Unfortunately, the more and more we, the software professionals get detached from users and usability, we become responsible for designing and delivering systems that fail to meet usability expectations.
Clearly, it is not enough if we 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.
Software Engineers do spot reusable components in the code they produce. Couple of days ago a young engineer in my team identified a reusable component from his code and wanted to release it to his colleagues. He approached me with his idea.
I asked ’Have you used this component in different contexts and found it reusable?'
He responded with a firm 'Yes' and agreed to take up the uphill task! He needs to make it usable. Am sure he will succeed.
Naturally, usable reusable components become reusable, live long and evolve!
Related Article:
Reusability, Usability and Flexibility
___________
No comments:
Post a Comment