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-paradigmes 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.
Maarten Katoen:
Hey Marnix,
I work a lot with PHP frameworks and came across the limitations of documentation.
At the moment, I work for a client with a pretty large website without a framework... If you look up the word spaghetticode, you'll find this website. On top of that, there's one senior programmer who knows all the ins and outs. This combination makes it hard to maintain the website.
Recently I proposed the use of a framework to make sure that there's way more structure in the code. Like you said, there will be (I hope!) a silent agreement on how things are done, so we don't have to worry about reading eachothers code all the time. However I find your solution very elegant (also for PHP ;) ). We didn't start out yet, but I'll definitly propose this solution.
I have one question as to how you would make a decision for a framework, since it can impact the need of proper documentation a lot. Would you go for a strict framework where there's one 'right' way to code or is a more loosely coupled system also the right way to go?
Keep it up! Great blog you've got going on here!
Marnix:
Hey Maarten,
That's an interesting question, to which the answer might differ per project.
I think, first and foremost, it's very important for you to start extracting as much knowledge as you can from that one Senior Engineer. You could make it clear to him that, to have knowledge equals a certain amount of product quality. Then, you could propose a few pair-programming sessions (of a few hours) in which you both try to implement a number of tasks.
This way he can guide you, when you drive the keyboard, and you learn his vision for the system and considerations when implementing code when /he/ is driving the keyboard.
Then, and only then, you could determine what a good framework would be. You need a certain level of knowledge about the system to be able to make such invasive decisions.
My personal preference when it comes to frameworks is simple. I don't mind being coerced into a certain predefined structure (or conventions) causing the code to look the same. However, if this is the case, there must always be a way to bust away from the framework to be able to do something that it wasn't meant to do. After all, a framework developer can, at no point in time, know all the use-cases, or needs, of its users.
In your case, I would probably suggest a loosely-coupled framework, since,spaghetticode tends to have a lot of places where the business logic is uncategorizable. By tacking on a thin layer to the existing code, you will be able to move over the codebase piece by piece.
Hope this helps!
Cheers,
Marnix