Sunday, August 13, 2006


The Quick and The Dirty

Experienced software engineers and designers usually already have a bag of tricks to pick out solutions from -- ranging from the most trivial routines to the most complex designs. After the countless years and projects that they have worked on, the skills they've learned, and the solutions they've deployed, they usually are able to distill the learnings into easy to recall and easy to implement techniques.

Some software projects (see Evolving a Giant) can benefit from these experienced engineers and designers -- but then the same forces encountered in these situations applied to even the most experienced engineers and designers can lead to another type of problem. This problem is something I like to call "The Quick and The Dirty".

The Quick Solution
Experience is the best teacher, and lessons learned through experience are hard to forget. To avoid complex solutions, a lot of engineers have found that if you avoid over-engineering a solution, you avoid a lot of the complexities associated with that solution. If they kept it simple and it works, they get the job done quicker than if they spent a whole lot of time over-engineering it.

The quick solution is usually effective -- it solves the problems, and creates less problems that need to be faced at the moment. The quick solution is usually sufficient especially if the enhancement/addition to the software is trivial and can be addressed with tricks from the engineer's bag. Of course, this assumes that the "solution" works, otherwise it's not a solution.

The Dirty Solution
Another thing experience brings is confidence. Usually, the more experienced engineers are more confident with their solutions compared to the solutions of those with considerably less experience or exposure. That leads to problems especially if you have a team composed of experienced and not so experienced engineers.

The dirty solution comes from both the experienced and the not so experienced engineers -- the solution becomes dirty if it needs to get cleaned up even after the solution has been deployed. Experienced developers have gone through the nightmare of maintaining their own dirty code, and the dirty code of others. This leads to the same problems that are encountered when working with a humongous software project that has already grown out of proportion.

Dirty doesn't necessarily mean not-elegant -- on the contrary, a lot of the "elegant" solutions are so complex they end up being more dirty than the quick solution (for examples, look at the merge sort and quick sort algorithm and compare these to insertion sort and even bubble sort). Dirty solutions have any one or all of the following properties (please feel free to add to them if you feel like I'm missing out on some things):

A solution can be a method, a class, an application, a framework, a design element -- or anything that is part of contributing to the solution of a certain problem. Dirty solutions work, but they are hard to maintain which is a reallistic problem that people in the software development industry face quite often.

Dirty solutions aren't really "bad", they're just dirty. If they're dirty, most probably they need cleaning -- so some people avoid dirty solutions at the cost of being slow.

The Quick and Dirty
Suppose the timeline requires a solution fast -- an experienced engineer under no circumstances will let the project run off track, because he knows how important keeping the project manager off his back is. But the same forces at work in "Evolving a Giant" are the same ones at play in almost all software projects.

These situations usually turn out quick and dirty solutions which are harder to find, and harder to fix.

Avoid the Quick and Dirty
Just like how you might avoid a black fly buzzing around you while eating your sandwich for lunch, you just might want to avoid these quick and ditry solutions. This section gives advice on how your organization can avoid these quick and dirty solutions, by putting in place some measures and techniques for minimizing the forces that bring about these solutions.

Experienced engineers are like artists --- they take their time when solving a challenging problem.

Haste makes waste, and experience teaches us this. Therefore, when planning and shceduling deliverables, leave ample room for leeway -- and plenty of time for Refactoring. Make sure that when they're in a productive zone that they are not bothered unless the building is on fire and they're not moving away from the workstation.

Being creative is easier than being harassed. You can't squeeze creativity out of a person, so don't even try.

If you're a project manager and are working on a timeline, make adjustments to the timeline as much as you can before harassing your developers. If you're a developer or a team lead, allocate enough resources (i.e. time and effort) to making sure that you stay as creative as you can be by taking enough breaks and keeping everyone fresh. Keeping someone fit to be productive is better than pulling a genius out of your hat.

If it doesn't look clean, then it's not.

If you find yourself writing a solution that doesn't look clean to you then it's not clean. Unless you yourself see it cleanly, you can't expect someone else to see it cleanly.

Making sure that your solution to the problem is clean will force you to stop worrying about the details and keep your eye on the overall challenge. Ask yourself if the solution you came up with is the cleanest possible solution you can think of given the time constraints -- as much as we want to have all the time in the world to figure out the cleanest solution, we just don't have it.

Making sure that your solution is quick and clean instead of quick and dirty takes a lot of effort. You will see that dirty solutions only postpone the agony of maintaining the system -- and like the wise people say, an ounce of prevention is better than a pound of cure.

Cliche's aside, the software industry relies on quick solutions to common problems -- so if your problem has been solved before, look at the solutions first before coming up with your own. After all, your limitation is a function of your experience and your knowledge: knowing this allows you to work on both and push your limitations further.

In an organization, it's important that you see your limitations and know how to work within them. So if you don't have enough experience, get as much as you can as soon as possible. If you don't have the knowledge, get as much of it as you can as soon as possible. That way, you'll be able to get quick and clean solutions like the experienced ones already do.

What's the use of being quick if you're going to the wrong place? What's the use of heading for the right direction if you don't start moving?

This page is powered by Blogger. Isn't yours?