Smart programming results in “dumb” programs.

S

Two of Loud Dog’s guiding principles are a focus on developing long-term strategic relationships with our clients and a focus on design and technology as business solutions. How is this reflected in our coding practices?

##What these principles mean in practical terms.

**First, we’re going to have to deal with this code down the road.** Since we’re trying to establish a relationship with the client, not just complete a one-off project, we’re going to have to work with the code again. Even if we don’t, we should deliver code that we wouldn’t mind working with – after all, someone else is going to have to work with it and I’d like them to think that it’s easy to work with rather than difficult.

**Second, we know and expect that business requirements and designs will change.** This is the fundamental assumption under Agile programming methodologies; only in rare projects do requirements stay consistent, and these are usually very large projects in very stable industries. In ours, they change all the time, during the project, after the project, even before the project.

This means that we make sure our code is:

* **clean,**
* **well-documented** and
* **very flexible.** (this is the most important one!)

##Client-side error validation as an example.

Our client-side (javascript) error validation code is a great example of these principals in action.

When I first programmed our error validation code back in 2000 or so, it was fully customized to every page. Although it enabled me to custom-make every page, it was tedious and difficult to maintain; whenever I wanted to duplicate the functionality, I had to recreate the function.

In the second iteration, I re-factored the code by including it in an external file. This way I just needed to include the file and submit the form to the function. It still wasn’t pretty because I included a bunch of javascript-generated text in the HTML to tell people what was required and to spit out error messages.

In the third iteration, Amelia (a former Loud Doggie) extracted the inline stuff and put it in the function. Now, we could easily create new forms with a minimal amount of special HTML (we had to have an empty div for the error messages, but that’s all). While this method made programming new forms super easy, if we wanted to change the forms down the road in response to changing business requirements (say a field is required in one but not another), we had to go edit the master JavaScript library, and ended up introducing all sorts of hacky things to make up for the differences in the form. This was easy to program, but **very brittle.**

In the fourth (and current) iteration, Matt (another Loud Doggie) completely refactored it to make it both **elegant** and **flexible**. With the new version, the main function contains a set of tests and validation scripts for popular fields (e-mail, telephone, etc.), and general instructions and responses (it auto-formats stuff, for example), but they aren’t required, but are called when the function is called.

So it’s very smart, but it’s also “dumb”: **it doesn’t make assumptions about what will be needed.** Instead, you have to specify which fields are required with each form. This makes programming new forms slightly more difficult, but in the end maintenance is much easier and the code remains clean.

##”Dumb Programs” are Smart.
My take-away is that we should make programs and code dumb. Making “smart programs,” based on assumptions about future designs, will only lead to lots of pain and suffering. If we only keep the most basic stuff on a high level, then we maximize our ability to change while still taking advantage of global variables, etc.

About the author

By Josho

Josho

Get in touch

Quickly communicate covalent niche markets for maintainable sources. Collaboratively harness resource sucking experiences whereas cost effective meta-services.