Maintainable code, performance, and command-lines

The push-pull of Maintainability versus Performance

Besides user behavior, one way to reduce the carbon footprint of the web is to write more efficient code. This goes beyond standard Web Performance Optimization (WPO) which typically addresses who well programmed components work together. Attention to code itself is deemed important, but not often discussed from a sustainability perspective.

Maintainable JavaScript, by Nicolas C. Zakas, is recent (2012) book that begins to address this issue. This book is a compliment to High Performance Websites and Even Faster Web Sites by Steve Souders, which define standard WPO.

Why?  Because maintainability is the opposite end of high performance, but both contribute to sustainability. In other words:

  • Highly maintainable websites may have reduced performance
  • Highly optimized websites with maximum performance may be harder to maintain

This book repeats much of the WPO wisdom that has appeared in other sites. However, compared to other WPO books, I found the overall descriptions to be more readable. Concepts are fit into larger systems of thinking throughout, rather than considering techniques in isolation.

Another unique benefit of this book is that it looks at code maintainability from a team perspective, rather than simple code optimization. By considering goals beyond CPU processing speed or memory, we address the big issue of keeping the site running efficiently during its entire life cycle. High performance may involve steps in code which make the computer faster, but are harder for human developers to understand after the fact. If code is pushed too hard to performance, future updates become very difficult. The means more work, possibly eliminating any benefit caused by increased speed.

One place where Maintainable JavaScript benefits everyone is by providing common style guidelines for code writing. Code is essentially one-dimensional – it feed through the CPU like a string of beads. We use the basic 2D formatting possible in a code editor to make the code human-readable. Zakas provides a lot of styles, and he takes some pains to justify his recommendations. We might not always agree, but I learned lots of new things from the book here alone, not the least of why some code has strange styles.

The final section of the book considers when automation (e.g. Ant) can help the development workflow. While there is a log of useful information there that can be used to automate workflows, I’m not sure it helps maintainability.

I appreciate automation in an 80/20 way. But if we try to push for more automation, I’m concerned that the development system might become so complex and convoluted that it becomes “brittle” to major changes in development workflow. Command-lines are typically very flexible, but a particular system may require a lot of magic words in an exact, modal sequence to make it run. This is a problem for smaller projects, where the cost of setting up automation and explaining it to a team may outweigh its benefits. In this, Maintainable JavaScript is similar to other WPO books – it assumes you’re working on a large project with lots of specialist team members.

Automation running through the command-line also excludes.  Only experienced developers who are comfortable with a lot of command-line can use many of these tools. Contrast that to a library like Modernizr, where a GUI interface allows effective customization.

Right now, the web is getting a big influx of new designers who understand stuff like typography and layout. These designers are game, and many are acquiring HTML,  CSS and JavaScript skills as they learn the “new letterpress.”

At the same time, the rising complexity of site code is creating a way for pure codebeasts to insulate themselves from design, hiding behind a scary black screen with arcane commands.

Automation tools uniformly require a deep understanding of “the Unix way” as opposed to “the Macintosh way” where many designers start from. If the web was a stable medium, a split between those who draw and those who open Terminal window might be O.K., but with rapid, parallel advances in both design and development, cross-fertilization is needed. Automation is useful, but let’s hope it doesn’t become a way to lock out designers for developers.

On their own, developers do design – they just don’t call it that. Their decisions at the code level constrain design to certain directions. Often the final webpage is a visual representation of the structure of their code libraries, rather than a user application. This “swiss army knife toolkit” approach was common in Web 1.0, and is something we try to avoid in modern UX. It would be a shame if a beautifully automated workflow didn’t allow design input at late stages in the development process.

The big question is: Does lots of automation help, or hurt agile design?

In the interests of making the web as a whole more sustainable, it will be important to push these automation methods into an “authoring layer” that less codebeast – web designers can use. The 80/20 rule would apply – get some automation that is easy to install and you get 80%, even though you sacrifice the flexibility of command-line tools beloved by the dedicated..

Handling the push-pull of site coding, between optimization and maintainability creates a larger framework than standard WPO. This  framework is another word for sustainability.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s