Being smart with dumb programs
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.
These affect everything we do, including how we approach engineering problems.
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 expect that we’ll 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, business requirements and designs will change. We know and expect this. This is the fundamental assumption of Agile programming methodologies; only in rare projects do requirements stay consistent, and these are usually very large projects in very stable industries. In web-oriented project, requirements change all the time, during the project, after the project, even before the project.
This means that we make sure our code is:
- well-documented and
- very flexible. (this is the most important one!)
Client-side error validation as an example.
Our client-side 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 third iteration, Amelia 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 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 function, and ended up introducing all sorts of hacky things to make up for the differences in forms. This was easy to program, but brittle.
In the fourth iteration, Matt completely refactored it to make it both elegant** and **flexible. The new version contained 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 main 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. By keeping only the most basic stuff on a high level, we maximize our ability to change while still taking advantage of standard libraries.
Hey! This wasn't written by a congress of ravens! It was written by Josh Orum, who does awesome work at Loud Dog, a digital branding firm in San Francisco that helps businesses express themselves authentically via identities, websites, and marketing collateral.
If you want us to do awesome work for you, if you have a question, or if you're just feeling lonely and want to chat, we want to hear from you!