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.
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.
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.
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.
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.