SCAR: a Java scaffolding solution

This post is dedicated to providing you with insights into the reasons why "code re-use" is applied; which, in turn, shows why these principles aren't always applicable to middle-sized software components. An answer to this problem is the SCAR tool that I developed: a tool that allows components to easily integrate with other software projects.

For years now, programmers would like you to believe that they are lazy, while in reality this really isn't the case. They just don't like doing things twice!

Tasks that return to our eyes time and time again are examined closer and are reduced to the press of a button; or to a reusable software component. This enables the developer to focus on the most important thing: searching to the solution of the problem at hand.

There are a number of ways to automate tasks:

• write tools that perform repetitive task automatically;
• abstract the task or functionality to make it reusable;
• sometimes the functionality are exists and a COTS can be deployed.

This usually works fine, hell, complete programming-paradigms and numerous best-practices are based around these principles, think of things like object-oriented programming. Unfortunately, it's not always sufficient.

The rest of this post is dedicated to providing you with some insights into the reasons why "code re-use" is applied; which, in turn, shows why these principles aren't always applicable to middle-sized software components. An answer to this problem is the SCAR tool that I developed: a tool that allows components to easily integrate with other software projects.

Reusable code: good idea.

Beside the fact that a programmer rather wouldn't do things twice, from a management point of view, there are a number of good reasons why you would want to apply code-reuse techniques.

When the techniques are applied properly, they cause a project to be done sooner rather than later. Less time spent on a project means that you can offer a project at a better price for your customer, this makes you more competitive in an already saturized market.

Every time a component is reused, small changes are made: an extra feature, some fixed bugs. This "software evolution" increases the quality and stability of the component. Better software means less bugfixing which in turns means less delays. Bugs and delays are the last things your customer wants to see.

Also, using standard components is a key factor in providing great focus to the problem at hand. So, by re-using code you will have more time to focus on problem- and domain-related code.

Too much abstraction is a bad thing

An approach taken to make code reusable is to create a component with a generic interface that has an incomplete or no implementation. When the component is used in a project, they holes that were left in the interface definition are concretized.

On a small scale, this approach works fine! Unfortunately, for a mid-sized component a generic interface is too restricting. It makes the developer over-engineer the extendability of an interface. Which, in turn, leads to a distracting and confusing component that is prone to bugs, and is unable to express its function in a straightforward and concise way. Even when the interface is very generic, it's impossible to provide room for each feasible implementation.

An abstract component needs a spot somewhere; usually, this is in a separate component project. Through time, the component is modified, variations will pop into existence and will need to be maintained. Suddenly, a good idea, turns into an administrative nightmare, and an endless pit of work.

So, we can conclude that creating a component that is too abstract is a bad idea.

SCAR: scaffolding archives

Looking at the problem described, and wishes that have been described above I have developed a new tool called: SCAR (scaffolding archives).

The solution direction above looks a lot like tooling that has been part of a number of web-frameworks; of which Ruby on Rails is one. They usually call it scaffolding.

Tasks that need boilerplate code; are repetitive or occur often can be put inside a scaffold. They contain complex code templates that take away a lot of the standard, mindnumbing work. Unfortunately, there was no Java variation available. Keeping the Rails scaffolding tools in mind, combined with the requirements stated above, SCAR has been developed.

A scaffolding archive:

• adapts to wishes and configuration settings of the project it is integrating in;
• is not an abstract layer, but a starting point, so there are no:
• extra libraries;
• limitations because of a rigid interface;
• difficulties with maintaining different versions in different projects.
• is extendable with custom plugins: when the instructions to integrate the component becomes too complex, the developer can extend the abilities of the tool to accomodate his wishes.

The code and integration instructions are packaged in a zip-file and placed in a repository (either locally or on a webserver), this is the SCAR.

Within our projects, we have started to use this tool. We noticed that it is possible to put not only mid-sized components in scaffolds, but also give repetitive tasks a place in SCARs. Everything combined, it has provided a renewed focus, including a refreshing speed with which boring tasks can be completed.