DEV Community: Ismael Velasco

How many emissions in a gigabyte of data?

Ismael Velasco — Sun, 21 Aug 2022 16:31:03 +0000

The Big Picture

In my post on the green potential of event driven architectures and AsyncApi I gave a high level overview of how to estimate the quantity of CO2 emissions generated by API traffic, and particularly REST APIs. Using the most conservative, lowest estimate of CO2/gigabyte I could find, I arrived at a figure equivalent driving all the cars in Shanghai for a year. Every year. Which would need the equivalent of doubling all the trees in Ireland. Every year.

This is the Big Picture we need to keep our focus on, which can be summarised as:

The more data we transmit or consume, the greater our digital carbon footprint
The amount of data currently transmitted is a significant contributor to climate change
Anything we can do to reduce data transmission, in volume, frequency or duration, through greener infrastructure, architecture and back-end and front-end design patterns such as green by default; and green mode design, we should do to shift the current dismaying climate trends.

At a more granular level however the Big Picture above is your motivation and theory of change, but it's not enough to translate vision into measurable objectives.

The challenge of measurement

Use cases

You need some kind of unit of measure for benchmarking your product's current digital emissions in order to monitor and measurably improve them. This could be purely at engineering team level, incorporated into your CI pipeline to stay within a carbon budget in your ticket implementations; or it could be part of a company wide digital Lifecycle Analysis (LCA), environmental management systems (EMS), or B Corp certification process.

So how much CO2 is generated by 1GB of data? This is a case in which why you measure is more important than how you measure.

Focus on the why

Bearing in mind the Big Picture above, you benchmark in order to make measurable progress, and choose a metric in order to monitor and communicate that progress. What really matters in most cases, is not so much the precision of your unit, but the trajectory of your product and organisation.

Not to say that the precision of your measurements isn't consequential, or that expert disagreement on exact bounds or ranges mean there are no bounds or ranges you need to follow to remain rooted in evidence!

But it is to say, that for most organisational purposes, as long as you are within the ranges indicated by reputable science (meaning pick a scientifically backed metric, even if it differs from another scientifically backed metric), the precise calculus of your units of measurement are less important than how much and how fast your emissions are improving (or worsening).

Much better to have a measure that turns out to be inaccurate to quantify a 50% annual improvement in emissions, and consistent progress over 5 years, than a measure with superior exactitude demonstrating 10-20% more emissions every year over the same 5 years.

Having said that, there is no exact and constant GB/kWh/CO2 correspondence, which is why there is quite a bit of scientific and policy debate in terms of arriving at precise figures.

Calculating data emissions.

Global averages

The most conservative recent figure is 0.015 kWh per GB by McGovern, and 0.0042 kg of CO2 per GB. The International Energy Agency (IAE) estimated in 2020 a 0.06 kWh/GB and 0.478 kg CO2/kWh footprint, which would result in 0.028 kg of CO2 per GB streamed.

So that shouldn't be too difficult right? Just choose one of the metrics above, and start calculating your CO2/GB benchmarks.

Hardware factors

Except, it is a bit more nuanced than that, if you're after precision. There is a difference in the emissions of the same GB of data by device type (e.g. mobile or PC), and by signal type (e.g. 3G, 4G, Wi-Fi) with mobile emissions calculated at 0.1-0.2 kWh/GB for 4G mobile, so a lot more than the metrics above.

It follows that if your product involves the Internet Of Things the intensity per GB will likewise vary if you're using a smart watch, a fridge, smart glasses, or an implant in your leg.

Problem is, once you've accounted for device type, not all device brands and and models within each device type are created equal, so depending on the age, brand and model your 1GB might produce completely different emissions.

Likewise what data communication protocol (e.g. HTTP, USSD, MQTT your device uses to transmit the 1GB of data to your device.

Got it. So if we just apply different CO2/GB metrics per device type, per signal type and per communication protocol, then, as the Brits disconcertingly say: Bob's your uncle.

Now can we go measure?

Software factors

Well, say you have 2 identical devices running on the same signal type via the same communication protocol. Different configurations, software installed, operating system, etc. will affect the electricity consumption of that identical machine upon receiving 1 GB of data.

It will be very different browsing on a minimalist Linux distribution like Porteus which is small enough to fit in an old USB stick and run entirely from system RAM, and browse 1GB or data using a text based browser in your terminal; than browsing 1GB of data a Windows OS opening 100 Chrome tabs while having 10 desktop applications open in the background.

So let's imagine you have 2 identical machines, identically configured, in identical conditions, with identical hardware and software running. Will your elusive GB now be equivalent?

Use case factors

Well actually, no. There is also a difference in emissions according to the what user behaviour that GB of data is meant to elicit. 1 GB has estimated to be equivalent to 600 web pages, or 30 minutes of HD video (caveat emptor: previous paragraphs apply!). By now, you've read enough to be pretty sure that your identical quantity of data will produce different emissions in these two scenarios... but can you guess whether 30 mins of data and CPU intensive video or 600 super optimised web page visits is worse for the climate?

If we take an average time spent on a web page to be 52 seconds (varies hugely between industries and between websites), then 600 pages is around 8 hours on your machine viewing its screen. That is 16 times longer than a 30 minute video.

Imagine that 30 minute video was transmitted in HD, not hosted in a green cloud provider, no steps taken to optimise delivery. Meanwhile those web pages were downloaded in a single optimised request via a super optimised CDN from a green cloud provider. Clearly the emissions generated by the GB of video traffic would be incomparably higher than those of your fantastically opitimized and delivered 600 pages.

Except, all that reckless, high emission, 30 minute video traffic, would STILL use less electricity than keeping your computer monitor, CPU, background processes, etc, in use for 8 hours.

Taking everything into account so far, and inaccurately working from a global average electricity mix, streaming a GB of video will produce around 18g of CO2. In contrast, a laptop that has a life of three years will generate, including embodied carbon, (107g of CO2 per hour of use)[https://www.hempoffset.com/2022/05/31/whats-the-carbon-footprint-of-your-digital-content/], so 828g of CO2: nearly 50 times the 30 minute video's footprint for a single GB of data.

Grid intensity

So now we're there, right? You just have to use the same machine to stream the same 30 minute video over the same network for your 1GB of data to translate into a single CO2 emissions metric.

Not by a long shot!

The emissions of your extremely frustrating GB will vary in relation to the location and time at which you stream your 30m video on the same device over the same network and protocol, hosted in the same server.

Emissions fluctuate in accordance with the intensity of the electricity grid at the time you stream a video. Your GB will produce more emissions when the grid is at high intensity, and less when the grid is being powered by renewable resources, so the same GB of data will produce more or less CO2 at a different time of day. There's a variety of APIs, like Electricity Maps (global), carbonintensity.org.uk (UK) and many many more, that you can use to measure your emissions in relation to grid usage, and make your websites and applications not just carbon aware but carbon intelligent.

An example of one implementation is the fantastic https://branch.climateaction.tech website. If you look top right, you will see it has 4 performance modes, giving you most functionality at low grid usage times, and reducing the defaults at high grid intensity times. So in low grid intensity mode you get full colour images displayed by default; in moderate you get them monochrome, and in high usage mode you have to click in order to see the image. The "Live" mode is a smart mode automatically switches depending on grid intensity.

You can see how they use the UK grid api to measure intensity in this simple JavaScript file: https://github.com/climateaction-tech/branch-theme/blob/master/js/gridintensity.browser.min.js).

Another implementation would be https://codecarbon.io/ which is more granular and calculates not just the emissions of your website or application in aggregate, but of your actual code, in accordance with grid intensity. This allows you to create carbon aware queueing jobs, which basically allocate the most computing intensive jobs to the lowest grid intensity times.

Track to improve, gradually refine

So is there then one answer to the question of how many CO2 emissions are in 1 GB we can use as a consitent metric? Alas no. Which is to say, tools like Ecograder in my first posts give you a nice starting point to benchmark and communicate your progress, but if you want to be thorough and maximally impactful, you need to drill down much more in both your measurements and implementations, with the tools and examples I've offered.

The most important thing, of course, is that whatever metrics and tools you choose, quick and dirty or orchestrated and precise, they help you surface your direction of travel in emissions, and empower you to reduce them month on month, year on year.

Could AsyncApi Make A Dent on Climate Change?

Ismael Velasco — Thu, 04 Aug 2022 08:38:47 +0000

It may at first sight seem like linking an emergent API specification to the biggest existential challenge of our time would be like asking whether a new format for restaurant menus might impact on the global obesity epidemic.

A closer look however suggests the AsyncApi specification, by accelerating and optimising event driven APIs, could help significantly reduce global emissions, in turn increasing our chances of impactful course correction. Let's break it down.

CISCO estimates that by 2022 a gargantuan 4.8 zettabytes of data will be transferred over IP addresses. More than all data transferred in the previous 32 years since the Internet was launched.

Using the most conservative estimates, that amount of data equates to 72 million megawatt hours which in turn roughly equals 20 million tonnes of CO2. This is the equivalent of driving 4 million cars for a year, and only accounts for electricity consumed in transfer, not data storage (data centres account for 1% of all electricity consumption worldwide), client device electricity, or the embodied carbon of data centres and devices. We would need to plant 620-920 million trees to offset that many emissions. These likely conservative estimates are subject to a lot of nuances, caveats and technical debate, but the conclusion is unequivocal: internet data traffic is a major source of pollution.

But we still haven't made the connection to AsyncApis! The next step in estimations is to roughly calculate how much of the traffic above is mediated specifically by APIs. One good proxy is Akamai, which routes 15-30% of all internet traffic. They found that 83% of all traffic through their network was API traffic, and only 27% was html website traffic. If this figure translates more broadly, which is likely, that would mean that some 16 million tonnes of CO2 are generated each year by APIs.

But what kind of APIs? In 2020 Smartbear's State Of API Report estimated 82% of APIs were REST APIs. A closer look suggests that 93-95% of APIs in their survey are essentially synchronous command response APIs, and only 5-7% are asynchronous, event driven APIs. Again, the precise numbers will differ, but the overall distribution is clear. A very significant proportion of those APIs are queried or query via polling, where repeated calls are made to see if there has been a state change. According to a 2013 estimate by Zapier, 98.5% of those requests return empty, meaning all the emissions involved across the request lifecycle are entirely wasted. The situation has almost certainly improved dramatically in the intervening 9 years, but is an example of the type of inefficiencies involved.

Which gets us closer to AsyncApi!

Increasingly, there is a shift from command driven, to event driven architectures, where instead of waiting for a specific command to trigger a behaviour, that behaviour is tied and automated asynchronously to changes in conditions, that is to say, events. This has huge potential and possibilities, which is why it is growing so rapidly as an architectural paradigm. Gartner projected that by the end of this year (2022)

Event notifications will form part of over 60% of new digital business solutions.
Over 50% of business organizations will participate in event-driven digital business ecosystems.
50% of organizations managing APIs will incorporate mediation of event notifications into their operations.
Most leading providers of application platforms will include high-productivity tools for event-driven design.

The environmental potential of switching from traditional REST APIs and similar command-request approaches, is that you can tie behaviour and consumption to climate aware triggers. You could apply graceful degradation when the grid is not running on renewables, and full performance when it is. You could have an IoT device automatically switch to low energy mode when it doesn't require constant activation. Instead of relying on people to remember to turn off lights or devices, they could be switched on and off upon detecting the user's presence or absence. Indeed, such architectures underpin most smart devices.

One of the greatest barriers to adoption of this paradigm, which could significantly cut into the amount of data transferred and energy consumed by the internet, is the historic absence of a common language to facilitate interoperability. This is where AsyncAPI (finally!) comes in. It provides a standard and a language to describe event based, asynchronous communication, greatly enabling not just inter-api communication, but also drastically cutting developer design and implementation time, by making possible a wide range of automations, akin to the more familiar OpenApi. Such a common language acts as a universal translator, which allows the emergence of a network of devices, workflows and tools attuned to one another in an emergent, inductive way.

In addition, the AsyncApi community has the historic opportunity, at this early stage in the spec's evolution, to dedicate serious attention to any way in which it could not just describe, but nudge the nature of event driven communication that is coming, or like Gibson said, is here, just not evenly distributed. It may be that there are elements that could be added to the specification that could greatly increase the environmental potential of all applications built in line with its specification. For instance, being able to flag whether a network is delay tolerant or not, could make a huge difference toward allowing a wide range of energy aware applications, as well as widening digital access and inclusion, and facilitating innovation, specially in the Global South.

This is a very early, yet therefore also a key moment. Event driven, asynchronous communication is, with cloud and serverless, part of the next (current?) wave of technological paradigms. If AsyncApi can enable and influence the transition from a command-request, synchronous, and climate blind ecosystem, to an event-driven, asynchronous, and environmentally conscious paradigm, then, after all this, yes, I do believe it could be part of making an observable dent on world emissions, and therefore on climate change.

2. Green Mode Design: Implementation Strategies

Ismael Velasco — Tue, 02 Aug 2022 17:01:44 +0000

In the second of the Green Mode Design series, I will move from the general design concept outlined in Part 1 to a first proposal on how it may be implemented by the four key constituencies: devs, consumers, browser vendors, and web standards/specification bodies.

Green Mode Design vs Green By Default

Before that I want to emphasise again that Green Mode Design, integrating both, "graceful degradation" and "user control and freedom", is not a replacement for green by default design. We should absolutely try and ensure that our products are as climate friendly as possible, before a user ever engages with our app. This is a space where not only developers but specially browsers and standards have a key role to play.

But even the greenest commercial website or app cannot impose a maximalist approach to CO2 optimisation and expect to survive.

What would Netflix or Youtube be without videos? Or with minimal viable quality videos only? What would a newspaper site be without images? What would a design agency website be if it was pure black and white? What would most web apps be without any JavaScript?

This is where Green Mode Design complements Green By Default design. The realistic default that meets not just the environmental, but also the economic and social pillars of sustainability, will still be more energy intensive than will be necessary at all times for all users.

If I go to youtube to listen, without watching, to a music video playlist - do I need to keep streaming the videos? Being able to toggle video streams and sound only would be not just good for the environment, but for my CPU and battery and general speed of my device, so not only "altruistic" consumers, but "selfish" consumers would want to toggle such a feature.

And where self-interest and altruism coincide, behaviour change is much easier to scale.

Additionally, given the realistic lag between advocating for Green By Default, and making it standard, Green Mode Design empowers users to override high emission websites to practice client side digital sobriety.

This means that emission reductions do not have to wait for sufficient negative consensus among all the stakeholders, but can start with consumers, which in turn will accelerate commercial and normative adoption.

Just one powerful green mode browser extension gaining traction across major browsers could potentially have a significant impact on both, emissions, and consumer awareness and behaviour.

What would Green Mode implementation actually look like?

There are many vectors out there that could be part of green mode design, but I think they could be integrated into 4 customisable modes and intensities of green mode design:

1) climate aware

client side optimisation without degradation (e.g. unused tab suspension, climate aware metrics/monitoring, ad/tracker blocking/service worker enabled intelligent caching).

2) climate friendly

graceful degradation of performance (e.g. all the above + more aggressive service worker caching; blocked image or videos by default, clicking on an image link displays it in a customisable default low-fi quality; clicking on a video link defaults to podcast mode (sound only), or even reader mode (transcript only).

3) climate first

maximum graceful degradation without loss of core functionality ( "print mode", no javascript, minimal css, maximum backward device compatibility, accessibility options (e.g. only text to speech including alt for images, and no other visuals; change font colour or size, etc - this + backward compatibility increases climate resilience)

4) smart mode

customisable default triggers for switching between 1-3 (High CPU, high daily CO2 consumption, full screen mode (degrade all other tabs), non-green cloud host detected, high CO2 website, time of day (this could link to focus mode design thinking).

What can be done already?

1) Consumers can achieve most of the above client side via browser extensions, but obviously it will be less seamless with more overhead than at the developer level, particularly in the absence of a Green Mode app that integrates all 4 levels in a comprehensive way.

2) Developer side we have all the tools to implement optional graceful degradation, like client caching both high performance and low fi versions of sites in the client (a bit like the prerendering used already in SPAs to serve crawlers and users different versions). You could also design every app and specially page for graceful degradation to work with low or no js. A lot of accessibility design would also be pertinent. And give your users high, mid and low performance options, plus smart mode, on your UI.

The only example I have come across (do you know any more?) of implementing all 4 modes I propose here is the fantastic branch magazine site. There is more graceful degradation options that could be added to each of Branch magazine's 4 modes in terms of user control and freedom, but this is a fantastic illustration of the design concept I'm proposing.

What cannot be done yet?

3) Browsers could but are yet to implement much more comprehensive green mode features than Edge's energy efficient mode, which itself is yet to be replicated by competitors.

If we could enable service worker type caching on the client side, with the same core strategies available, that could potentially have large impacts on data consumption and computer usage. If you could for instance toggle a feature that implements stale while revalidate strategies if no similar service workers are active from the site itself, you could drastically reduce web traffic and consumption.
if you could download rather than stream by default, with streaming mode operating only as a buffer until the full download completes, that could also make a difference, specially if you could "expire" the downloads after x time, removing the downloads by default, and giving the user power to keep the ones they like.
if you could integrate CO2 counters into the browser itself, or at least to dev tools and lighthouse and equivalents, that could also become a powerful behavioural nudge. There are doubtless many, many more ways in which browsers could enable the proposed 4 layers of Green Mode design. Please share any suggestions or ideas.

4) The other potentially game changing element that is yet to land, would be specifications and standards to integrate both, green by default, and green mode by default.

Sites that conform to green and green mode standards could be prioritised by search engines and similar incentives, as is the case with Accessibility.
Green mode design support (user controlled graceful degradation layers) could perhaps also be incorporated into OpenApi and AsyncApi specifications. This would align with trends in delay tolerant networks, set to proliferate in the coming decade driven by commercial, environmental and humanitarian interests.
Green certifications could be mainstreamed and integrated into things like Amazon's Green Pledge certification and other impact multipliers.

Where to next?

At the moment the 4 key constituents (consumers, devs, browsers and standards) are at different places in this design trajectory.

Consumers * I suspect consumers are proportionally and numerically the furthest in commitment, but lack the means to express it technologically in the web space.

Green marketing and even green washing are successful because consumer demand is real. So a browser extension could be the most rapidly scalable win, with the most downstream impacts.

If there is evidence of demand, it follows that software conventions and web and browser standards will change more rapidly. If we could reach a tipping point, we could radically improve our industry's environmental impact on emissions, waste and raw materials, with many secondary benefits.

The biggest limitation in this area is the fact that browser extensions do not work on mobile.

Developers *

Assuming the statistics on people's readiness to make changes to protect the climate, I estimate that there are c.9 million developers waiting for the right messaging, tooling and behavioural nudging to implement greener software and design practices, particularly among younger ones.

This means that those of us who have been advancing the practice of climate friendly design and programming, including ideas such as Green Mode Design, need to step out of the "green" community and bring the messaging, tutorials, libraries and resources to non environmental communities.

Gaining support for incentivising green software in key platforms, from the big cloud providers, to ecosystems like android and apple stores, NPM, Steam or Github.

Above all, it means systematic efforts to incorporate green approaches and perspectives, including Green Mode design, into the junior developer pipelines at scale. Computer Science and adjacent university curricula, bootcamp curricula, popular webdev trainers on YouTube, Udemy, etc, and professional development gateways like Pluralsight, or accreditation bodies like ISAQB.

Browsers *

The most impactful space for Green Mode design is probably at the browser level. Given the acceleration of sustainable consumption patterns and priorities this could be a source of competitive advantage and traction.

With 60% of mobile wallets being in Africa, Green Mode options, compatible with less powerful mobile devices, delay tolerant networks and less intensive data plans, Green Mode functionalities at the mobile browser level could hugely expand commercial reach and digital inclusion in the Global South.

For browsers associated with a hardware ecosystem, the opportunities to extend battery life, reduce energy consumption and increase usability are particularly strong.

Extending at least green extensions/plugins functionality to the mobile browser sphere could also greatly enable innovation and change user behaviour.

I believe sustainability discussions are ongoing in many browser companies. These need to deepen, widen and be more publicly visible, and bodies like the Green Software Foundation and the UN ITU could play a role in thus.

Standards and Specifications *

Work is currently underway to establish a Sustainable Design Working Group able to make recommendations to WC3. The United Nations Envoy for Technology is also currently consulting on a new Global Digital Compact to shape national regulatory approaches. The UN Secretary General's projected Forum of the Future has digital components across most priority agendas and the Internet Governance Forum brings together governments and civil society stakeholders.

The green web/green software community needs to be present and proactive in these processes which have the potential to influence international government policies for a long time to come. Tracking the standards and regulatory environment around green web indicators would be an important first step, and the Green Web Foundation is probably well placed to lead on this, perhaps through its Fellowship programme.

Finally, the Green Software community needs to engage with emerging specifications and protocols, like OpenApi, AsyncApi or MQQT.

These are of course broader strategies than Green Mode Design, but Green Mode Design could be one impactful low hanging fruit that could be part of the above strategy and vision.

I would love to hear from colleagues if they resonate with these proposals, and what alternatives or refinements might be needed. Together I truly believe we can shift the environmental direction of the Internet.

If You Treated Technical Debt Like You Do Financial Debt... How Would You Measure Your Risk of Going Under?

Ismael Velasco — Thu, 21 Jul 2022 01:20:41 +0000

Today we take a deep dive into technical debt: what is it, when is it good, when is it terrible, how to measure it, how to cost it, how to address it.

So what is tech debt?

Very often, tech debt is defined as a conscious trade off of quality for speed, or a result of poor design decisions. But while both of those are good examples of tech debt, tech debt can also come to absolutely top quality code: if it fails to evolve with the tech ecosystem. The cutting edge app of 2010 is very often the creaky, slow and plainful monolith of in 2020. It's not that the original choices were suboptimal: it's that time moves fast in tech, and code needs to constantly evolve to keep in sync.

But not all technical debt is created equal.

Below is a model you may find useful in mapping different parts of your application.

Technical Debt Accounting Model

### Low Interest Technical Debt

Technical debt, like financial debt, can be useful, helping you enter the market and gain traction with an MVP, or allowing you to innovate, or rebuild. That's when your debt is "low interest", you understand the trade offs and the pain is in your future, with a plan to pay it back before it gets painful.

### High Interest Technical Debt

High interest debt, that's risky, and much harder to pay off. Here your technical pain is not ahead but right now, and if you're nor careful, it will compound into a debt default. Technical debt now places serious operational and commercial constraints on the entire company, and creates reputational risks, from security breaches to service interruption.

### Technical Debt Default

This is where your company is at existential risk because of technical debt. Your core platforms may have passed End Of Life with widely publicised critical exploits, and you advertise this in your website headers. Your system has become so bloated and is so highly coupled that no one really knows what everything does, and everyone is afraid to change things because every change creates side-effects. Your new features grind to a halt, your devs leave, your company stagnates and loses users to more reliable competitors.

Technical Debt Accounting

https://youtu.be/McO_ONKxwNU

So equipped with this model for understanding and categorising your technical debt, the questions of implementation remain:

How do you rigorously measure it to know in which category any given part of your codebase falls?
How do you know which specific classes are most tightly coupled or more likely to create side effects or most difficult to understand?
How do you measure the impact, as opposed to the presence of technical debt on your team or company's feature development process?
How do you estimate its financial cost?
How do you choose which areas of the code to refactor first?
How do you know when replacement is the only option?
How do you persuade the business of the need to invest in technical debt?

Metrics for measuring technical debt which I cover in my training course include formulas for code complexity, cognitive complexity, class and method complexity, afferent and efferent coupling (one is likely to have side effects in many parts of the code, the other is likely to be vulnerable to changes in many parts of the code); package dependency metrics and more. There are also powerful visualisations which can help you find the seams in your application, identifying the low hanging fruit for modularising or service decoupling, as well as the highest risk areas. The metrics above have also proven to be 70-80% predictive of bugs, so they allow you to identify likely bug prone classes and methods.

A different type of metric is escape velocity, the amount of times new work releases bugs into production. There are algorithms like szz that estimate this in repository commit histories, both globally and by file.

A different approach uses issue trackers like Jira. You can create queries and even dashboards that quantify and monitor live the rate at which tickets previously marked as done are reopened. You can also track the number and rate of tickets marked as "bug" or "fix", the time it takes to respond to a bug, and to resolve it. These process based metrics are particularly important because they help you quantify and cost the compounding of technical debt into operational and strategic debt. You can track how much time is spent on bugs and fixes, and this is time deducted from new features, with associated opportunity and competitiveness costs, and also user pain points, which can affect adoption and retention.

These process metrics allow you to put financial estimates to your technical debt. You can track how many hours your product team (inc. devs, managers, product owners, qa, customer service) spend on bugs, and get pretty precise figures of pro-rata aggregated staff costs. If you compare this to revenue, profit and turnover streams, you can see how significant a cost that is beyond the raw amount, as it might negate the entire profit from a product vertical. You can also, more roughly, estimate the cost and frequency of roadmap delays or slowdowns, against commercial projections predicated on them as a proxy for opportunity costs. Finally you can make correlations between customer acquisition and retention and bug introduction rates as well as customer complaints. This kind of analysis is essential to get business buy-in for investing in technical debt, and for identifying where in my proposed framework your product might be.

Technical debt also compounds in to security debt, as it almost always entails vulnerabilities that can be tracked and measured via static analysis tools like Sonar, or API testing tools. Finally, technical debt compounds into environmental debt, as you can link speed, requests, data transmission, server intensity, infrastructure configuration and more to higher CO2 emissions, battery and CPU usage, and several downstream and upstream costs. This could have implications to your ESG accounting, your brand values, and your transition to Net Zero.

You can find an illustration of the above framework, metrics and tooling in a talk I recently gave on the subject. Indeed, you may have noticed I added a new Tech Talks section. OK, no way you noticed. It has recordings from meetups, conferences and even COP26 on a wide range of software engineering subjects. I will periodically introduce one here. I started with Technical Debt, because I am genuinely thrilled to have been selected to give a 1 day online workshop on the subject in November by the International Standard in Training and Certification of Software Architects - probably the world's foremost software architecture certification body.

To be dedicated 9 hours (there's also a follow-on talk on Modernising Monoliths) at one of the world's leading architecture conferences, at the invitation of such a literal standard setter, feels humbling, exciting and challenging, all at the same time. The talk above can be taken as a taster for my online workshop, which will actually train you to apply this framework, tools and metrics in practice.

If you enjoy it, you might want to sign up for the (online) workshop. Do please share any feedback on this blog post or the talk above, and suggestions for things I should clarify or add ahead of the course.

Also check out the entire conference and training days, there are some really fantastic talks in the programme!

Green Mode Design Through Graceful Degradation

Ismael Velasco — Wed, 13 Jul 2022 20:19:22 +0000

Wouldn't it be great if you could toggle green mode on the websites you consume and greatly lower your CO2 emissions, make your battery last longer and extend the life of your devices?

What is Green Mode design?

What I'm choosing to call Green Mode design is the combination of two UX principles:

user control and freedom: allowing users to control their experience of the system while providing means to undo their selections.
graceful degradation: the ability of a system to degrade its performance without affecting its core functionality.

So Green Mode design could be defined as:

_ giving users a reversible option for degraded but still functional performance in exchange for reduced emissions and longer device life. _

It surprises me that I have so far only found a single website (do you know of any others?) with a green mode toggle: https://theorganicagency.com/our-website-green-mode.

I would have thought there would be hundreds if not thousands of examples, given we learned the art of "graceful degradation" well over a decade ago, and so many of us deeply care about climate change.

The rise and fall of graceful degradation

Graceful degradation, in web development, generally means that you build your site to take advantage of all the features of the web APIs supported by the latest browsers, but also create fallbacks for people using older browsers or devices.

Interest in graceful degradation peaked around 2011, because the difference in CSS and Javascript support between browsers was massive, particularly with Internet Explorer 8, which had the least functionality and the largest market share.

This meant that every website had to cater to both, the shiny new kid on the block who excelled at gymnastics (Chrome would edge out Internet Explorer by 2012), and the less than athletic grandparent who controlled the PCs. To grow and retain your website's user base, therefore, it became common practice to create a high performance version with a low performance fallback for laggards. To experience a good example of graceful degradation, if you have access to gmail, go to your inbox on the browser, and once there, disable javascript. You will get an option to view your mailbox in html only. Accept and behold graceful degradation in action. Before: After: As the web api became more standardised, and browsers more interchangeable, graceful degradation largely faded from developer discourse, as an artefact of an earlier, more painful era. You could now safely let rip and flex your web muscles. Which of course also meant that we were pretty much responsible for exponentially increasing planetary emissions, with more and more powerful applications requiring more and more energy and imposing faster and faster hardware obsolescence and waste.

Implementing Green Mode Design

Many of us are familiar with the eco mode option in cars. When enabled, the system modulates things like air conditioning, heated seats or other functions to take away pressure from the engine.

The benefit is better fuel efficiency, lower emissions and cheaper costs. The trade off is that it inhibits the performance of the engine (acceleration, gear shifts), and degrades things like lights (less bright) and air conditioning (more interruptions, less power).

While eco mode is ideal for most trips, it's not suited for driving up steep hills, or accelerating quickly to overtake. Choosing maximum performance would make more sense in these situations, both for safety and for the car's health and longevity.

Similarly, you might not choose graceful degradation on a website for high end gaming, watching a blockbuster, or sleuthing through image based OSINT.

But for day to day use, you probably don't need all the animations, background videos, images and trackers when reading articles, listening to music on YouTube in the background or aimlessly procrastinating.

Will the real slim browsers please stand up?

If the option for excluding such "extras" when requesting web pages was a standard feature available to the 5 billion people that use browsers, the impact of even fractional adoption would reduce global emissions in a noticeable way.

And yet, compared to consumer electronics, the web ecosystem has been slow on the uptake, to put it politely. Green Mode Design (in practice if not in name) is fast becoming standard in consumer devices, with eco mode an option from wearables to laptops, mobile phones to whole smart houses.

It was only in the last year that Microsoft released a still little known feature, efficiency mode.

It aggressively reduces CPU and RAM usage by lowering video and animation quality and putting to sleep unused tabs. This is a pretty weak offering, considering that the tab suspender extension is much more powerful and fine grained.

I have not come across any efficiency mode equivalents in Chrome, Safari or Firefox. Some of the features are replicated, like tab sleeping and more esoteric optimisations like wake up javascript throttling, but they are not designed as user controlled options, so they do not conform to my definition of Green Mode Design, offering graceful degradation but no meaningful user control and freedom.

It is a bit bizarre then for the web to be so far behind this curve, when there is so, so much that could be done by browsers to offer truly customisable green mode options, with potentially huge impact on climate change.

Does that mean that green mode is largely impossible for responsible consumers?

Hacking Green Mode on the user side

While there is no native, comprehensive tool to achieve meaningful and customisable green mode in browsing the web, there are ways to "hack" a green mode approximation for responsible net surfers thanks to the efforts of enterprising devs in the browser extension ecosystem. I have already name checked Tab Suspender:

As you can see you can create powerful rules. As a pathological multi-tabber (if multi-tabbing was a sport, I'd have a shot at the Olympics), this has been a godsend. After my chosen interval, the tab goes completely inactive, while its ghost remains ready to come alive on my return: My CPU and ram usage has, since I added the extension, been very dramatically reduced.

Other extensions allow you to block (not hide) adverts from youtube videos; block (not hide) videos from youtube, only streaming the sound, which is great if you use youtube for music or podcasts.

Yet more extensions allow you to disable JavaScript with a quick toggle on a single page (as opposed to the browser as a whole in the settings).

There are extensions to automatically choose the minimum resolution of videos you stream (the greatest source of web emissions on the user side).

You can also use extensions to monitor your web consumption and emissions, and there are also extensions that plant trees every time you open a new tab, or search the net, or shop online.

I hope to devote a separate blog post to this extension ecosystem.

It has inspired me to set myself the goal, this year, to create an open source "green mode" extension, that integrates all of these features and more in a granular way.

Reclaiming Graceful Degradation for Green Mode web design

Instead of designing fallbacks for antiquated browsers, like we used to as standard practice, web developers could design fallbacks for user facing "green mode" toggles, which should be present in every web application we're responsible for.

Ideally we would offer more than on/off options. You could have green/greener/greenest options, with increasing levels of degradation that do not break core functionality.

That way you could go from this: https://moves.basicagency.com/

To this (beware, heavy swearing ahead): https://tinyurl.com/sweary-but-ecofriendly

With less extreme options in between.

Call to action

Consider this post an invitation to all web developers to reach into our drawer and dust off the graceful degradation manual, and reclaim it as a tool for climate action.

Just as developer design choices have been instrumental in our industry outstripping aviation as polluter, developer design choices can be instrumental in making our industry a lever of sustainability.

1. Green Mode Design Through Graceful Degradation

Ismael Velasco — Wed, 13 Jul 2022 20:19:22 +0000

Wouldn't it be great if you could toggle green mode on the websites you consume and greatly lower your CO2 emissions, make your battery last longer and extend the life of your devices?

What is Green Mode design?

What I'm choosing to call Green Mode design is the combination of two UX principles:

user control and freedom: allowing users to control their experience of the system while providing means to undo their selections.
graceful degradation: the ability of a system to degrade its performance without affecting its core functionality.

So Green Mode design could be defined as:

_ giving users a reversible option for degraded but still functional performance in exchange for reduced emissions and longer device life. _

It surprises me that I have so far only found a single website (do you know of any others?) with a green mode toggle: https://theorganicagency.com/our-website-green-mode.

The rise and fall of graceful degradation

Implementing Green Mode Design

Many of us are familiar with the eco mode option in cars. When enabled, the system modulates things like air conditioning, heated seats or other functions to take away pressure from the engine.

Similarly, you might not choose graceful degradation on a website for high end gaming, watching a blockbuster, or sleuthing through image based OSINT.

Will the real slim browsers please stand up?

It was only in the last year that Microsoft released a still little known feature, efficiency mode.

Does that mean that green mode is largely impossible for responsible consumers?

Hacking Green Mode on the user side

Other extensions allow you to block (not hide) adverts from youtube videos; block (not hide) videos from youtube, only streaming the sound, which is great if you use youtube for music or podcasts.

Yet more extensions allow you to disable JavaScript with a quick toggle on a single page (as opposed to the browser as a whole in the settings).

There are extensions to automatically choose the minimum resolution of videos you stream (the greatest source of web emissions on the user side).

You can also use extensions to monitor your web consumption and emissions, and there are also extensions that plant trees every time you open a new tab, or search the net, or shop online.

I hope to devote a separate blog post to this extension ecosystem.

It has inspired me to set myself the goal, this year, to create an open source "green mode" extension, that integrates all of these features and more in a granular way.

Reclaiming Graceful Degradation for Green Mode web design

Ideally we would offer more than on/off options. You could have green/greener/greenest options, with increasing levels of degradation that do not break core functionality.

That way you could go from this: https://moves.basicagency.com/

To this (beware, heavy swearing ahead): https://tinyurl.com/sweary-but-ecofriendly

With less extreme options in between.

Call to action

Consider this post an invitation to all web developers to reach into our drawer and dust off the graceful degradation manual, and reclaim it as a tool for climate action.

A starter kit for building climate friendly software

Ismael Velasco — Sat, 02 Jul 2022 01:58:00 +0000

When you think about climate change, it's easy to feel fatalistic. Not an unfamiliar feeling to anyone who has had to face the Big Bad Ball of Mud for the first time.

And when you read more about it, it's easy to feel not just fatalistic, but guilty, seeing as the code you continuously deploy into the wild, the apps you lovingly (or frustratingly) maintain, the servers you consume, account, when added to the work of all your peers, for as many CO2 emissions as the whole of the aviation industry! Everyone tells you to cut down on flying, but who tells you to cut down on <video> tags?

Still, we're not fatalists, we're software engineers: problem solving is what we do. Every week we get to feel like crime scene investigators, obviously doomed idiots, and certified geniuses, twice over. In a single day.

Being responsible for so many emissions, counter-intuitively also gives us an extraordinary opportunity for postive inpact. By applying green software patterns and integrating things like tree planting apis, we can build not just low carbon, but carbon positive digital products. Given the scale of much of what we work on, if just a small percent of us commit to a green web, our impact on emissions could be exponential.

Still, if you're like me, you may not know how to start. Green web patterns are not yet regularly discussed in meetups, tutorials, vlogs and general dev land. So here are some resources that might help get you started.

The green web journey began for me when I stumbled across this fantastic blog piece by Phil Sturgeon of Build APis You Don't Hate fame.

Soon after, I was invited to organise a panel and present at COP26+ on Engineering and Climate Change at the invitation of the International Environment Forum. I instantly thought of Phil, who graciously agreed to join me, and two other superb speakers, on what proved to be an insightful and empowering exchange. The experience made me aware of the power of engineering communities to both inform, and motivate, and I set about looking for the best one in the tech space.

I am confident I found it in https://ClimateAction.tech. They have built a fantastic and impactful green tech community, including many of the pioneers and leading voices in the green software movement .

From their website you can join the Slack group which is probably the best single place to keep track of developments, network with fellow travellers and ask questions.

Other good resources to get started are:

The Green Software Foundation and its podcast, Environment Variables

The Well Architected Framework's Sustainability Pillar

And resources like awesome earth and https://www.cloudcarbonfootprint.org

As to the skillset involved in environmentally aware software, I suspect you'll find you already have a strong foundation.

It just so happens that what's required for green tech is exactly what's required to reduce costs, cpu usage, improve speed and user experience in any web application! These should be part of the arsenal of any experienced engineer, and part of the journey of every committed junior one.

Move your application to a (greener) cloud provider/zone
Make your content delivery as local to the client as possible (e.g. via CDNs)
Minimise your page loads and data consumption by targeted caching strategies using service workers
Design your APIs to minimise http requests and data exchanges
Optimise your images and reduce the javascript and in general the data you send to the client front end, by minification and exclusion.

So while you may not have thought about the emissions side too much to date, I suspect you already know a thing or two about performance optimisation, api design, caching, and graceful degradation/progressive enhancement for "digital sobriety".

Which means you're already set to go on your green journey, equipped with a community, good resources, and your own accumulated skill.