Approaches to Development - Hacking

I’ve been thinking recently about the different ways that solutions can be developed - the different approaches taken by different people to the same problem.

There seems to be something fundamental about the different approaches, and I’ve put Pen to paper (or key to screen as it were) to express some thoughts.

This first article looks at the advantages and disadvantages of hacking solutions together from the applications you already have.

Introduction

There are many ways in which the development process can be approached - different techniques that have different benefits and drawbacks. Use one in the wrong place and you can buy yourself a whole heap of problems.

To begin with, this article looks at a hacking approach to development.

The word Hacker, in the context of this article, is used in it’s original (complimentary) sense, not the distorted, darker meaning that has resulted from the misuse of the term by the media and by a certain disreputable, thought technically competent, sector of society.

Solution Hacking

To hack together a system is to take the pieces you already have, and combine them together in a novel or ingenious manner to achieve the desired result.

This is often done by combining applications that are already available with some kind of scripting language that coordinates the actions of each. The typical Unix toolset for the manipulation of text files, and the scriptibility of most shells, are both good examples of this.

Characteristics

Performance: The performance of a hacked solution is usually dependent on the performance of the underlying pieces that are being combined. If the underlying pieces are themselves suited to providing high performance (whether measured in throughput or response time), then the hacked solution may also provide high performance. If the underlying pieces are not so suited, then nothing will improve things.

Off the Shelf pieces: Often many of the pieces used are off the shelf applications - sometimes commercial, many times free and/or open source. This usually gives benefits in terms of initial reliability and performance of the system.

Advantages of Solution Hacking

Appropriateness” Because hacked applications are typically developed on the spot for a particular, well defined, business (or personal) need, they are almost always exactly what is required for that situation. Further, as the requirements change over time, further refinements to the solution tend to maintain the appropriateness of the solution. The counterside to this is that hacked applications are only maleable within certain bounds - if changing business requirements move outside those bounds, the entire system becomes obsolete in one stroke.

High Speed of Development: Hacked applications are sometimes developed in minutes, but more regularly in hours or maybe a day or two. It’s rare for a developer to set out to hack for days and days, but sometimes it does happen.

Low Cost of Development: Because of the short time frame involved, and because many of the favorite tools of the application hacker are themselves free, the overall development cost of a hacked system can be very low. This is sometimes somewhat offset by a higher cost in ongoing maintenance.

Timeliness: Hacked solutions are always appropriate for the moment, and because of the low time of development, are available for use quickly. This makes them very useful in the face of urgent requirements or changes to the business.

Flexibility: Because the system is so malleable - a direct consequence of the speed and style of development - it can usually be adapted to meet new requirements without a great deal of work.

Disadvantages of Solution Hacking

Reliability: Hacked applications will usually work very well at handling the usual case - the things that happen every day, or that were anticipated by the developer. Feed them the unexpected, however, and things may fall apart. One key aspect that distinguishes the ability of a developer to hack together a solution is the way they anticipate the unusual and protect the system from failure.

Brittleness: This is intimately bound up with reliability is the brittleness of the system. When faced with a change in conditions, does the system keep working, or does it fall over in a screaming heap? Depending on the system, either of these may be the correct answer.

Poor Portability: Hacked systems are often intimately bound to the context in which they are developed - not just the computer itself (or the system of computers), but the business needs of the organization ( or person). This often makes the transfer of a running system to a new machine, or to a new business, extremely difficult.

Lack of Documentation: When a system is created from scratch a few minutes, or just an hour or two, the temptation dwells for the developer to consider the system so self explanatory that it need not documentation - that the scripts (or code files) themselves are sufficient. The problem here is twofold. Firstly, that you need to be able to find the scripts before you can read them. Secondly, that the scripts will only capture the mechanism of the application - and not the intent. When someone else (or the original developer, in two years time) comes to read the files, they will be lacking crucial business context.

Highly Personal: Hacked applications tend to be extremely personal, and specific to a particular person - or to a small group of like- minded people. When the original developer moves on to another role (in the same or another company) the knowledge behind the hack often goes with them.

An Example of Solution Hacking

Some years ago, I worked in a support role looking after a number of teaching computer labs. The computers in these labs needed to be constantly maintained in a state of readiness, primarily because they were used by classes where the students were new to computer use.

Making life complex for me as an administrator was a requirement that the machines appear to be completely open to the user, because many of the courses were oriented towards preparing the students to work with computers when they entered the workforce. Thus, locking the systems down so that only authorised activities were possible was not an option.

Additionally, there was a certain, “disruptive” element, already familiar with computers, who took some delight in the tweaking of machines - changing fonts, colors, mouse speed, that sort of thing, entirely in order to frustrate the other students.

To address the maintenance of these computers, I hacked together an automated system.

On restart, every machine connected to a central server and downloaded a configuration file that described the permissible contents of the hard drive. The local hard drive was then scanned, and any file that was not permitted either deleted, or replaced with a known good copy (downloaded from the server).

This ensured that rogue applications, additional fonts, extra words in the spelling dictionaries and so on were quickly cleaned up.

Students were allocated storage on a central server for their files, but any document that was inadvertently saved on the hard drive was moved to a “Lost and Found” folder, and kept for 8 days (long enough to be recovered during the next lesson of a weekly class).

While the configuration files on the server were originally hand written, after a time I created a database that listed the required files and folders for each application available for lab deployment. This allowed the specification for any one lab to be changed in just a couple of minutes, with the result that the machines in that lab would apply the changes next time they restarted.

Since every machine automatically restarted every night between 2am and 3am, any changes required would be available for use by the first class the next day. Urgent changes could be accommodated by manually restarting all of the machines in a lab and thus triggering the updated process. Installation of any application onto an entire lab (typically 22 machines) could be achieved in well under an hour.

Conclusions about Hacking Solutions

Hacking a solution together can be a very useful way to “ get the job done”. Development is fast and the result is almost always a good solution to the problem at hand.

The limitations and drawbacks of the approach need to be considered as well - attempt to hack a solution in the wrong situation, and you can paint yourself into a corner.

Here is a summary of what we have discussed.

Advantages

• Appropriateness;
• High Speed of Development;
• Low Cost of Development;
• Timeliness;
• Flexibility.

Disadvantages

• Variable Reliability;
• Brittleness;
• Poor Portability;
• Lack of Documentation;
• Highly Personal.