Worksoft Certify Reusability

What is the use of reuse?

Reusability – this is something which we talk and focus a lot in any given project. But what actually it is and is it really important?

Ok so let me take you in past when we had no such theory. ‘Control + C’ and ‘Control + V’ were the only available tools for reusing any existing code. Splitting the parts of code from principal logic caused uncertainty.

It was a hard time. Right!!

Then the ray of hope – object-oriented programming (OOP) was introduced to the world. And the world fairly ignored it initially until the graphical user interfaces, which turned into reality where the importance of OOP was felt.

Hereafter, OOP took off.

We at SOAIS try to reuse the already developed content to its maximum in any given Worksoft project. To be precise, our developers in particular write scripts (code) that can be reused within the project. This has really paid off quite brilliantly – we are able to finish the projects well in time and quickly.

But let me make it very clear that one cannot just write any script and then expect that it can be re-used. Script reuse requires proper communication among team members so that people know what script is available, and how to use it. Basically, I suggest below three points which needs to be followed by the project team:

  • communication on the script’s features/capabilities
  • instructions on how to use it
  • commitment to maintain and improve the script over the time

On a large scale, we try to eliminate any script duplication as much as possible and then we have a full library (a folder) with a lot of reusable scripts.

Usually we develop the script for one application and if we find it generic enough then we promote it to the library. This works outstanding. When we start automating any given script we automate it with an assumption that it will be reused, even if in reality that is highly unlikely.

In Worksoft automation script reusability is an extremely important factor. Where scripts are not reused, projects get harder and longer, however, writing reusable scripts takes little more time.

Specially, we at SOAIS try to write all our scripts in a reusable manner, this takes little time to develop, but it ends up with the fact that most of our scripts becomes the bona-fide infrastructure in our projects and with these infrastructures our projects take significantly less time. This becomes more crucial when we work on a big project where we have 14/15 team members and we need to automate an enormous number of business processes.

Since there are always two sides of the coin so there is some amount of danger involved in reusing scripts as well. If the reused script is not developed as a potential infrastructure – with as few as possible presumption and as much as possible documentation then the script can end up doing some random/unexpected things. Hence, we at SOAIS design and develop the script with not only one requirement in mind, but to think of future requirements and try to make the design flexible enough to cover them with minimal change. In addition to that to keep the script maintenance low and reusability high, we strictly adhere certain key approaches and procedure:

  • give very clear and descriptive names to the script
  • avoid duplicating the names
  • always mention the detailed descriptions in the script
  • use commenting to describe action steps/logic in the script


Always remember that developing reusable script is not about developing generic, consistent scripts. The key to develop reusable script is to develop focused, compatible components with a high adherence and loose pairing. Keep your script germ-free. Aim for developing focused scripts with a low complication and easy to maintain.

Documentation – If you are developing something keeping reusability in mind then you must not forget that documentation will be extremely important to the success of your project. Reuse is something that is easy to say than to do. Doing it requires both clever design and very good documentation.

Naming – Standardize the naming convention to provide a clear and meaningful name and avoid duplicity.

Training – Don’t be frightened to ask for help or to provide help. Educate yourself and train others. We at SOAIS do this naturally via many different ways. If we find difficult to approach team members, then we schedule a development session to discuss the problems and its solutions. We also keep tracking the problems that come up quite frequently.

Coordination – If needed our team can defer if we see reuse is going to be likely/un-likely in the future and this save us time in the long run. Everybody in the team are aware about the script that we delivered even if they aren’t involved in the development process. Personally, I believe that collective ownership and effective communication is the mantra for project success.

It seems very contradictory that something that is so painful and lavish to create can have so tiny value. I guess that’s why so many people and for that matters organizations too like to pretend that their scripts are much more serviceable than it really is.

Contribution by Gautam Jha