This post is a companion post to the “Automation do’s and don’ts”.  Here I will examine organizational hurdles that stall the creation of reusable components.

The reuse of software is a common object stated by most companies, but, with exception of a set of narrow cases, most companies struggle with this objective.  In my experience, there are 6 reasons for this struggle

1. Lack of ownership:  There isn’t a group (or person for smaller companies) who has the responsibility and authority to ensure this task succeeds.
   Note: often the lack of authority on the person/groups part is the larger part of the problem.
2. Failure to allocate time:  Turning a component into a reusable component can add between 10% to 15% to the development time.  If time is not budgeted for the additional development a “buggy” reusable component is released.
3. Lack of awareness/documentation: The greatest software tool is useless if no one knows about it or it is poorly documented.
4. Narrow use case: The component is created and its’ use is so limited that only a few people will ever use it.
5. Wide use cases: Wide use cases often lead to complex reuse components that either do nothing well or become so bloated that they are difficult to configure and maintain.
6. Bugs: Every time a person uses a “reusable component” and it fails to do what it is supposed to do it encourages people to not look at reusable components.

So how do you avoid those pitfalls?

What type of reuse?

I break down reuse into two categories, formal and informal.  Informal reuse is common for individuals and within small groups.  It is when a component is regularly used to perform a task by people who know how to use it well or are able to work with its’ “quirks.”

Informal reuse is a good practice however it should not be confused with formal reuse which is the topic of this post.  With formal reuse, the component is used by people who are not experts on the underlying assumptions and methods of the object.  Because of this they are not tolerant of “quirks” and need a solution that is dependable and documented.

It should be noted that many “failed” reuse attempts arise out of taking informal reusable components and treating them like formal reusable components.

Deciding when to reuse

Before I automate a process I ask myself the following questions to prevent the “to narrow” and “to wide” blocking issues.

1. How often do I perform the task?
   Once a day? Once a week? Once a quarter?
2. How long does the task take?
   How long does the task take both for my self and the system running the process?
3. Do others perform this task?
   Do they follow the same process?  Does variance in the process cause problems?  Do you have a way to push the automation out to others?
4. How many decision points are there in the process?
   Decision points are a measure of the complexity of the process.
5. Is the process static?
   Is the process still evolving?  If so how often does it change?
6. Is it already automated?
   Oddly enough if you found it worthwhile to automate someone else may have already done the work.
   

Taking responsibility

Issues 1 (lack of ownership) 3 (lack of awareness and documentation, and 6 (bugs) can be addressed by having a person or group who has the task of creating and maintaining components

The maintenance of the component has three primary tasks.  First, the creation of test cases to ensure the component continues to work as expected.  Second, updating the component to support new use cases.  Third, knowing when to “branch” components to keep them from becoming to complicated.

Time

For some organizations allocating time to the development process can be the greatest hurdle to creating reusable components.  The time invested does not show an immediate return on investment and there are pressing deadlines.  However, if the rules of thumb in “deciding when to reuse” are followed the long-term benefits will outweigh the short-term cost.

Final thoughts

The final topic is how to encourage engineers to actually reuse the components.  This is, in part, dependent on how well the components are documented and how easy they are to accesses.  In the end, they need to understand how it benefits them; e..g less time spent “reinventing the wheel” and more time to work on their actual projects.