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:
* **well-documented** and
* **very flexible.** (this is the most important one!)
##Client-side error validation as an example.
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 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.