In my first blog post Towards Leaner Software, I wrote about the importance of runtime performance in terms of CPU and memory efficiency. After reading the paper “Energy Efficiency across Programming Languages”, I realized I hadn’t given much thought to energy consumption of programs and had assumed (incorrectly) that faster execution corresponded to better energy efficiency. If engineers choose languages, data structures and design patterns that result in the least energy consumption, it will help software run better on mobile devices and cloud data centers, two areas where computing is growing the fastest.

Having worked as an application developer for over 5 years now, I’ve noticed how, generally, there’s a lack of motivation and incentive to build robust, correct, secure and fast application software. While I’m fortunate that my team at GoDaddy does focus on these aspects, right from the design phase, it’s doesn’t apply to all. Furthermore, the higher a developer works in the application stack, the smaller the chance that they invest their time and effort into imbibing these characteristics into their code.

With the rise in popularity of microservices, Docker has gained popularity and has become the standard for containerization. Its ease of use in software delivery using containers has put it ahead of other containerization technologies such as rkt and LXD. I’ve lost count of the times I’ve come across popular official Docker images that were bloated and riddled with bugs and known vulnerabilities. This causes many developers to shun them in favor of building their own alternate images, causing duplication of effort, developer time and storage space and costs.

In his 1995 article “A Plea for Lean Software”, Niklaus Wirth wrote: Software expands to fill the available memory Software is getting slower more rapidly than hardware becomes faster Wirth explained that the two causes for bloating of software are the rapid growth in hardware performance and customers' ignorance of features that are essential vs nice to have. 25 years on, Wirth’s Law still holds true. At a time when a software product’s power is measured based on the number of features, the rampant incorporation of all possible features that users may want messes up the software design and causes quality and performance to take a backseat.