Author: ewernli

SAFe: What’s a Release Train Engineer?

SAFe introduces a new role in the industry: the release train engineer (RTE). A RTE is, according to the framework:

The Release Train Engineer (RTE) is a servant leader and coach for the Agile Release Train (ART). The RTE’s major responsibilities are to facilitate the ART events and processes and assist the teams in delivering value. RTEs communicate with stakeholders, escalate impediments, help manage risk, and drive relentless improvement.

The role is designed like a scrum master at the ART level. At a minimum, a RTE ensures that the process is followed. But a good RTE helps teams improve their performance – that’s the essence of the job. A RTE doesn’t have any authority over the content in the backlog. The focus on only on improvement at the organisational level. As such, the wording “assist the teams in delivering value” leaves quite some lattitude in how impactful an RTE can be.

What do you expect from a RTE? I am wondering how this role will establish itself in the industry. Here are my personal expectations.

Level I – The Organizer. The RTE ensures that the process is followed. He/She ensures that information flows between the teams using the elements of the framework. The RTE helps resolve problems related to the work environement as they appear. Example of such problem could be: tools to communicate, organisation of the program backlog, running the ART events. He/She makes sure people can work.

Level II – The Moderator. The RTE is able to create plattforms or use existing plattforms to encourge discussions in the ART / Solution. With some moderation talent, he/she can help instill change, support improvements, or create alignment. The RTE helps resolve problems about team performance as they appear. Example of such problem could be: interpersonal issues, improving the collaboration with a specific provider, managing morale in challenging time, ensuring transparency, suggesting a feature stop to address the existing bugs first.

Level III – The Influencer. The RTE identifies systemic performance issues in the organisation and work towards resolving them by instilling change at the organisation, technical, or product management levels. Example of such issues could be: addressing systemic quality issues due to the work culture, working with the system architects/teams/system team to make the continous delivery pipeline faster, encouraging decentral decision-making (while managing risks), improving feedback loops.

The higher the level, the more interdisciplinary the RTE will have to work. While little knowledge of product management or architecture is needed to be proficient at level I, problems at level II and III will require a good understanding of how engineering works and how product management, technology and processes influence each others. On the technology front, the RTE is also a key stakeholder to support mindset like DevOps, which means he must also have some good understanding of how technology supports delivery and operations.

The RTE role ressembles that of the more established delivery manager. Both focus on similar sets of issues.

The big difference between both roles lies I think in the mindset. A RTE is a coach and as such has little formal authority in itself. He leads by helping other take the right call. A delivery manager will typically have more formal authority. For instance, a RTE has no authority over the priorisation of backlog in itself. The PM and PO have formally this responsability. The RTE coaches the PM/PO in priorizing work.

The higher the level, the more the RTE works at the level of the engineering culture. It’s easy to define values and visions that nobody follows. Culture is defined by how people effectively behaves. It’s hard to be a good RTE. Just like it’s hard to be a good scrum master. Changing how people work isn’t easy.

SAFe: Systems Thinking

I was pleasently surprised to see Systems Thinking as principle #2 in SAFe. I recently came in contact with systems thinking when reading Limits to Growth, which explores the feedack loops in the global economy. Donella Meadows is also the author of Thinking in Systems, which addresses more generally how to understand complex systems dynamics with such feedback loops (the book is in my list of to-read).

This is the definiton of systems thinking according to SAFe:

Systems thinking takes a holistic approach to solution development, incorporating all aspects of a system and its environment into the design, development, deployment, and maintenance of the system itself.

It’s quite general. But arguably, there isn’t one definiton of systems thinking. If you read Tools for Systems Thinker, the study of feedback loops is only one aspect of systems thinking. The more general theme is to understand the “interconntedness” of the elements in the system.

A system is a set of releated components that work together in a particular environment to perform watherver funtions are required to achieve the system’s objective. – Donella Meadows

Principle #2 in SAFe is about realizing that the solution, but also the organisation, are complex systems that benefit from systems thinking.

Interestingly, Large Scale Scrum (LeSS) also has systems thinking as principle. It’s more concrete than the equivalent principle in SAFe. The emphasis is on seeing system dynamics, espectially with causal loop diagrams. The article is a very good introduction to such diagram. Here’s an exmaple of a very simple causal loop diagram:

I like the emphasis on actively visualizing system dynamic:

The practical aspect of this tip (NB: visualizing) is more important than may first be appreciated. It is vague and low-impact to suggest “be a systems thinker.” But if you and four colleagues get into the habit of standing together at a large whiteboard, sketching causal loop diagrams together, then there is a concrete and potentially high-impact practice that connects “be a systems thinker” with “do systems thinking.”

The idea is that it’s only when you start visualizing the systems dynamics that you also start understanding the mental models that people have, and only then can you start discussing about improvements.

I like the more concrete way to address system thinking in LeSS as in SAFe. Recently, I discussed with our RTE about some cultural issue related to knowhow sharing. Using a causal loop diagram would have been a very good vehicule to brainstom about the problem. I think I will borrow the tip from LeSS and start sketching such diagrams during conversations.

SAFe: The Good Parts

The Scaled Agile Framework (SAFe) is a complex framework. I mean, just look at this picture:

Long is gone the simplicity of Scrum. Its glossary contains 102 items (I counted them!), ranging from obvious concepts like a “story” to esoteric notions like “set-based design” with “customer centricity“ in between. The framework is meant to impose some structure, but at the same time, it has so many elements that with some creativity, you can probably retrofit any organisation in it without changing anything (for instance by abusing the concept of shared services). If agile was meant to be about simplicity, then SAFe is far from it.

SAFe comes in various “configurations”. The picture above is “portfolio” SAFe. And mind you, there is a “full” SAFe configuration which is even more complicated. But the core of SAFe – the “essential” configuration – has actually good parts:

  • An agile release train (ART) is a collection of teams. They synchronize through the program backlog and the PI Planning (PI stands for “program increment“)
  • ARTs should align with value streams. You organise you company in ARTs based on how you generate value to your customers so that each ART focuses on one part of the value stream. The definition of value streams is of course complicated in the glossary, with development and operational value streams distinct from each others, but the idea is actually good. You align IT and Business this way.
  • At the ART level, the leadership is split across three roles: Product Management, System Architecture, Release Train Engineer. I think that this split is a nice point in SAFe. It creates some balance in responsability and makes it clear the to be efficient, you need to address product features, architecture, and work culture together since they all impact each others.
  • SAFe also introduces a special terminology for things that aren’t features on their own: enablers. Chances are, you had this kind of work item already, just with a different name. But naming matters, and SAFe make a good use of the concept of “enabling” at various level. I like it.
  • Community of Practice as the naming for working groups around specific issues.
  • The System Team helps with toolchains, infrastructure, build pipelines, integration testing.

Most companies develop their own organisation when growing, which will have some similar elements. Maybe you have different roles (e.g. “engineering managers”), or different ways to synchronize, or some other way to manage architectural work. Some things are surely different, but some things are probably similar, but named differently, or implemented differently. If you want to move to SAFe, how much you will need to adapt will depend. But for most enterprise, the change isn’t radical.

In this sense, SAFe is as collection of patterns. What SAFe gives you is a standard frame of reference to discuss about these aspects. SAFe establishes a common vocabulary to talk about the organisation and how to improve it. Where this analogy with patterns fails, though, is that you usually can decide to implement some pattern individually. SAFe come as a framework of patterns, where all of them must be implemented.

The „large solution“ configuration adds an additional level of scale with product management, train engineer, and architecture at the solution level. Solution and ARTs have the same cadence and synchronize through the same PI plannings. They have the same program backlog. This makes sense. (Historical note: “Program Level“ was replaced with “Essential” in SAFe 5, but the rest of the “program” terminology survived)

With the “portfolio” configuration, you have an additional level of “lean portfolio management” (LPM) whose goal is to « align strategy, funding and execution ». This adds epic owners, enterprise architects, lean business cases, KPI and the like the framework. According to the framework, only with this configuration can you achieve business agility. Something I like with SAFe is that idea to fund value streams rather than projects.

I understand that this level may match well with existing organizations, with funding systems and steering boards. But the portfolio level still has a bit the feeling of ARTs and Solution Trains as “factories”, divorced from real business accountability. If the goal is to bring IT and business closer to each other, why not push these elements to the ARTs and Solutions? Make them accountable for the value their products generate. In a way, I wished that this level wouldn’t exist, or existed in another form – for instance not beeing an addtional level but rather a vertical that complement the existing levels. I understand that some initiatives will impact several steps in the value stream, and thus possibly several ARTs or Solutions. But I hope it’s the exception, not the norm. On the other hand, maybe that’s also precisely the point of the portofolio level beeing above the Solution / ARTs. If your business (and thus value streams) isn’t yet clearly establisehd, you need another level to be able to shape the value streams based on feedback from the market. I think that the portfolio level will be used very differently from enterprise to enterprise.

In its core values, SAFe recognizes its influences: Agile development, Lean product development, systems thinking, and DevOps. The framework actively tries to combine these influences into a consistent whole. The problem is that it feels sometimes a bit too much: The SAFe core values page lists 4 values. The lean-agile mindset page lists 4 pillars. The SAFe lean-agile principles page lists 10 principles. The lean-agile leadership lists 3 dimensions. Business agility lists 7 competencies that are required (on the left in the picture, but “competency” isn’t in the glossary). I like conceptual frameworks, really. But it’s hard for me to not get lost here.

I guess that companies moving to SAFe will still need to tailor it to their needs anyway. Where I’m working, they added „subject-matter expect“, for instance. That’s fully in the idea of agility- tailor processes when you need it. But with this idea in mind, SAFe could have been kept smaller rather rather than trying to be all encompassing.

SAFe: Evolution Over the Years

It’s very interesting to see how SAFe evolved over the years. The version 2, circa 2013, looked like this:

Some things are worth noting:

  • There is no large solution. Only Team/Program/Portfolio
  • At the program, we find release management.
  • The symmetry between PO/Team/ScrumMaster and PM/Arch/RTE isn’t yet established
  • Spikes and Refactors, a terminology comming from eXtreme Programming
  • Epics are primarily characterized as something that spans releases, to be broken down into features that fit in releases

Interestingly, this setup is very like the structure I know from my work.

This is version 3, circa 2014:

There aren’t that many changes compared to v2. The biggest change seems to be the introduction of value streams at the portfolio level. With it comes the ideas that we fund value streams. We also see some “principles” appear, like the House of Lean, the Lean-Agile Leadership, Built-In Quality at the Team Level.

Here is version 4, circa 2016:

Major changes include:

  • An additional level between program and portfolio: the value stream. The “Solution Train Engineering” from version 5 is a “Value Stream Engineer”. The value stream is very present in this configuration.
  • The symmetry between PO/Team/SM – PM/Arch/RTE – SolMgmt/Arch/VSE is established
  • Release management is subsumed with shared services
  • Community of Practices appears
  • Some additional “principles”: Economic Framework, MBSE, Set-based, Agile Architecture, Core Values, Lean-Agile Mindset, SAFe Principles.

Here’s version 4.5, circa 2018

  • Value Stream Level is replaced with Large Solution Level. With it the Value Stream Engineer becomes a Solution Train Engineer.
  • Supporting artefacts and teams regroupped in a sidebar.

Here is the current version 5.1:

We have several major changes (here’s an detailed analysis of them)

  • The introduction of “Business Agility” as the overarching goal, to be achieved with the profolio level.
  • Introduction of the 7 core competencies (Organizational Agility, etc.)
  • The levels Program and Team merge into “Essential”.
  • Some more “principles”: customer-centricity, design thinking.

By studying the evolution of the framework I understand some things better now.

  • The core of the framework with agile release train and portfolio levels remained quite stable over the years
  • The large-solution level appeared over time, morphing from the value-stream level. The symmetry between the ART and solution level with the 3 roles PM/Arch/RTE took some time to evolve to how it is now.
  • The term epic became more complicated to understand. It started as “something bigger than a release” and existed only at the porfolio level. In SAFe 5, epics can occur at all levels.
  • Supporting artefacts and teams evolved over time, but these were much minor changes. The biggest change was probably the “subsumption” of release management in the shared services.
  • Principles have generously been added continously to the framework. There are now a lot of them.

Just with anything that evolved, some inconsistencies accumulate. I find it interesting to observe this in domains other than code and architecture. For instance, in SAFe 5 the term “program” is still in use (Program Increment, Program Backlog), but the program level disappeared. This is due to historic reasons. Starting directly with the version 5, you would probably name things differently (e.g. “Solution Increment”). Also just like with code and architecture, the framework suffers from feature creep.

Somehow I’m a bit sad that they decided to go away with the “value stream level”. The idea of value stream is very powerful and putting in at center stage was nice. The version 4 has another spin as version 4.5. from an engineering standpoint. With the “value stream level”, various programs deliver independent products that together realize a value stream. With the terminology “large solution” of version 4.5, you get the impression that you have one “large solution” broken down in several components deliverd by various ARTs, that need to be integrated together. The difference can seem subtile, but I prefer the spin of version 4. The “large solution” terminology will tend towards centralization more than the “value stream” terminology.

As for the principles, there are simply too many of them. I believe that the signal-to-noise-ratio here is too high.

Introducing business agility is an interesting move from SAFe. I expect the discussion “development agility “ vs “business agility “ to be all the rage in the coming years. We know how to do agile development. But we still don’t get the expected outcome at the business level. The link is somehow not that trivial as in theory. Version 5 recognizes this and makes it clear that agile development is a mean to an end, not the end itself. It reminds us why we’re making all this. Here’s there’s a clear signal without noise, and it’s valuable.

Stuff Matters

img_3072

Stuff Matters is a very nice little book about the materials that surround us. Organized in ten chapter, each tracing the history of a class of material (metal, paper, glass, plastics, chocolate, gels, graphene, concrete, ceramics, biomaterial), we get to better appreciate how much tinkering and research took place over centuries to discover all these materials and their properties.

Most materials in the book are materials we know and can relate to. We know their basic properties, for instance, that rocks are solid, don’t melt easily, and don’t conduct electricity. Having two young children discovering the world, I marveled at how much they still need to discover. For a large part, we learn from personal experience. But we also learn through school, reading, movies, art, architecture. Materials are everywhere and are an integral part of our society and culture. That’s one theme of the book and it resonated well with me.

Mark Miodownik is a good storyteller. When talking about materials, there’s always a human context that makes the story relatable and engaging. For instance porcelain isn’t just porcelain, it’s also the story of Chinese emperors trying to impress their rivals with refinery and sophistication. At the same time, the book has its good share of technical details. We learn about the structure of many materials, including several modern “high tech” materials such as graphene and aerogel. The book even mentions invisibility cloak, how cool is that?

The whole book is interspersed with personal anecdotes. They don’t feel forced and I enjoyed them. Mark Miodownik commands his subject for sure and is passionate about it. I loved the anecdote about him being profoundly impressed by the Crown Jewels of England as a kid. Not because of the luxury they represent but because of their “primitive” materials, mostly pure gold and gems. We can really feel that his passion for the subject came at an early age. And passion is contagious. This book is a nice example of it.

Adventures in Memory

adventuresmemory_rgb150dpi

If you try to think about the last talk that you gave to a large audience, you might recall feeling a bit anxious standing in front of the audience. You might remember people looking at you and how the room looked like. This memory feels complete. Yet, you don’t recall the actual faces of the people in the room, or the details of the room, or the exact setup. This is the magic of memory. Memory is reconstructive.

This particular aspect of memory is one of the many aspects of memory addressed in the book from Hilde and Ylva Østby, “Adventures in Memory: the Science and Secrets of Remembering and Forgetting“. The title is well chosen. The book takes you into a journey about memory, explaining some facets of memory in a tone mixing popular science, journalism, and story telling. Originally written in danish, the cultural references in the book make you travel a bit in scandinavia. It was a refreshing change.

Beside the fact that mermoy is reconstructive, you will learn in the book for instance the difference bewteen semantic and episodic memory; how memory is triggered by places or music; that some people have weird perceptual experiences like synesthesia; techniques to learn random digits; the role of false memories in the judicial system; how remembering and dreaming trigger the same brain activity; what post traumatic disorder really is; and get a confirmation that forgetting things is normal.

I probably actually have already forgotten a lot of details of the book and the list in the paragraph above is far from exhaustive.

As a teenager I always wondered how come that some friends could recall and tell stories way better than me. It turns out I have now the explanation. Our memory isn’t a functional unit that’s identical in every individual. Everybody has a different memory that profoundly shapes who we are and how we experience the world. Mermoy isn’t only about storing facts, it’s also intimately tied to our perception and imagination.

Maybe memory has always fascinated me without me realising it: some of my favourite movies are Be Kind Rewind or Eternal Sunshine of the Spotless Mind. But funilly I had never read anything about how memory works. I’m glad I bumped on this book by serendipity.

More

A Comparison of Mobile Messaging Architectures

A project I’m working on involves changing the messaging technology for the delivery of realtime information to train drivers using iPad. This project made me interested in the various ways to design realtime messaging plattforms for mobile clients.

Unlike realtime messaging systems for web or desktop applications, mobile applications have to deal with the additional concern of unreliable connectivity. This unreliable connectivity is more subtle than I though. Here are for instance a few points to consider

  • no connectivity or poor connectivity (tunnel, etc.)
  • the device my switch from 5G to WLAN
  • connection breaks when app goes in the background
  • Different WLAN HotSpots (Androis, iOS) result in different behavior

You need to design your application to support these use cases correctly.

Here are some aspects of the communication that you need to consider

  • Does the client need to load some state upon connection?
  • Have updates a TTL?
  • Are messages broadcasted to several clients or unique for the clients?
  • Is message loss important or not?
  • Does the server need to know which clients are connected?
  • Do you have firewall between client and server?

Depending on the answers to these questions, you migth decide to establish a point-to-point onnection from the device to the backend. If you want to broadcast information to several clients you need to do this yourself in this case. You will also need to manage the sate in the backend yourself. Tracking the presence of the client is trivial, since there is one connection per client. Several technologies exist for this use case:

  • Server-Side Event
  • HTTP Long Polling
  • gRCP
  • WebSocket

You might otherwise decide to rely on a messaging system with publish-subscribe. The most common protocol for mobile messaging in this case is MQTT, but there are others. With a message broker, the broker takes care to broadcast message and persist the state according to the TTL. Tracking the presence of the client can be achieve with MQTT by sending a message upon connection and using MQTT’s “Last Will Testament” upon connection loss.

There are of course more details to take care when comparing both approaches, especially around state management. For instance, how to make sure that outdated messages are ignored.

We chose the latter option (MQTT) for our project, but I’m sure we could have achieved our goal with another architecture, too.

MORE

Apprently Uber and LinkedIn rely on SSE:

The Planet Remade

The Planet Remade, a book by Oliver Morton, explores the possibilities and implications of geoengineering – that is, the intentional modifications of the earth’s climate.

The argument in the the book can be summarized as follows:

  1. Climate change represents a risk. Depending on one’s position on climate change, the risk might be bigger or smaller, but there is a risk nevertheless. We ought thus to address this risk.
  2. Reducing carbon emissons, as a way to mitigate climate change, is way harder than most think. There are two challenges with reducing carbon emission. The first is that the benefit is delayed for a long time – decades. This makes it hard to create a momentum. The second is that that we don’t have good a “lever” where to act. Reducing carbon emissions substantially also requires substantial pervasive investments. For these reasons, the following known approaches are hard to pull off:
    1. Direct Air Capture (DAC)
    2. Carbon Capture and Sequestration (CCS)
    3. Ocean pH decrease
    4. Reforestation
  3. A high level of CO2 in itself (that is, if we omit the greenhouse effect and its impact on climate) is not a bad thing. Plants and photosynthesis have evolved billions of year ago when the air had much more CO2. High level of CO2 actually benefits vegation significantly. Models show that such a planet might be greener.
  4. Geoengineering technology to negate the greenhouse effect and cool down the planet should be considered on our way to a sustainable planet. Several geoengineering approaches could be envisonned to achieve such a cool down:
    1. Stratospheric veil
    2. Increased cloud brightness
    3. Increased plant reflection
    4. Increased ocean reflection
  5. The stratospheric veil is the only technology that offers a good “lever”. With a small fleet of airplanes, enough material could be injected in the stratosphere to achieve a significant effect. Also, the effect comes relatively quickly.
  6. We do have some understanding of such veil through the observation of volcanoes. It doesn’t mean that we have enough understanding now to use it without risk, but it means, this approach has potential. It requires more research and if possible, experiments. The best substance for the veil is for instance unclear. Volcanoes emit sulphure, which has some drawback.
  7. Veils have some negative effects. It is still a better option than the negative effects of an uncontrolled global warming. Effects of the veil isn’t homogeneous – some region might benefit but some might be hampered by it. A minimal veil with regionally either a positive effect or at worst zero effect, should be doable.
  8. Reducing carbon emissions and geoengineering a veil are not exclusive. Many people dismiss geoengineering out of fear to lose the focus on carbon reduction. But both are complementary and the best angle to look at, is the research geoengineering to create a “breathing gap” for the transition to zero carbon emissions. The veil isn’t a permantent solution, only a temporary one. With this strategy, we also reduce the risk of the “termination shock” – the risk of forced stop of the veil in the future should we not be able sustain it. Morton warns that researching stratospheric veils as Plan B, in case of emergency, will not lead to solutions that work when needed.
  9. A planet-wide transformation of natural cycles raises moral challenges. As a matter of perspective, we must consider that
    1. we have already transformed the planet at a global scale. For instance, the extensive and systematic use of fertilizer is akin to geoengineering of the nitrogen-cycle.
    2. we actually do already have a veil with a cooling effect because of pollution. As policies to reduce polution stengthen, this veil will disappear, possibly “unmasking” more warming due to greenhouse gases. A geoengineered veil could be seen as a replacement for this polution veil.
  10. Geoenginering belong with nuclear to technologies with powers beyond the human scale. Both could wreak havoc on the planet, or be used for better goods. The justified fear of nuclear technology in the context of nuclear wars doesn’t mean we should put geoengineering in the same basket.

The book doesn’t follow strictly this order – this is my summary after reading. Instead the book is organized in three parts – energies, substances and possibilities – and explores several tangents. The first part expains the basics of climate science and sketches the argument. The second part goes deeper in the various approaches to geoengineering. The third part gives perspectives about the fate of the world and how things could play out. This structure did sometimes feel like meandering, but it worked for me.

Where this summary of the book doesn’t do justice to the book at all is about its coverage of history. I read on wikipedia that Morton has a degree in history and philosophy of science. This penchant for history is clearly visible in the book, which reminded me of books like Energy and Civilization or Stuff Matters. The book retraces the history of many scientific discoveries, which I found entertaining and informative. Moreover, it also addresses the political and moral side of climate mitigation and geoengineering, as well as the shifts in perception of technology over generations. The current “mainstream” perception of technology could change again for topics like geoengineering or nuclear energy.

Books of this kind are usually either written by scientists or journalists. The former might lack storytelling, the latter might lack depth. Morton is a journalist, but also himself active in this “geo clique” since many years. Morton has a great command of the topic but also a good storytelling.

The book left me unsatisfied about two points, though. I would have liked that Morton better explain the view of people against geoengineering and provides a better rebuttal of their points to back up his argument. I also wished he had better explained why stricter policies around carbon emissions are so hard to set up. We successfully did this for CFC and are doing it for sulphuric emissions, so why not carbon? If the answer is that carbon emissions originate from a lot more place, why not start first with strong policies specific to certain industries?

Knowing little about climate science, I certainly learned many things about it reading the book.

  • the difference between stratosphere and troposphere
  • the ozone layer (nice complementary to the ozone story in Limits to Growth)
  • the fact that the stratosphere isn’t homogenous
  • the role of oceans to reflect sunlight but also evaporates water
  • the albedo-effect
  • the Trenberth diagram of energy flows
  • the role of temperature difference as the source for weather
  • the effects of carbon, nitrogen, sulphate, methane, NOx in the air
  • the effect of light diffusion on photosynthesis
  • the geological times
  • the explanation for ice ages
  • levels of CO2 over time
  • the climate is defined by more than a temperature: wetness, dryness, temperature cycles define the climate too

Coming from computer science, “the cloud” means for me internet. Now, the term has for me regained its original meaning with great interest.

More

Limits to Growth

I read this book after reading Factfullness, from Hans Rosling. It was a lucky coincidence. In Factfullness, Rosling argues that our model of the world is often wrong and imprecise. In Limits to Growth (LTG), the authors work out, step by step, such a model.

The model that the authors present is aimed at understanding how growth will continue up to 2100. The authors do not argue that the model captures every possible aspects impacting growth. They are well aware that it’s a model, with some simplification in it. What they tried to do, is to make it usefull for their goal. In this regard, the model is well argumented and realistic. The limits of the model are also disclosed transparently – for instance, the model has no notion of geography or politics.

The situation now in the world is already unsustainable – we are facing overshoot. The formidable challenge up to 2100 is to solve overshoot for the current population, but also to improve the system to accommodate 4 billions people more.

At its core, the model is based on a few key abstractions, which are presented linearly in the book.

  • The first abstraction is the world population. Population growth is controlled by income level and global health measures that reduce death (here you see the link with Factfulness very clearly).
  • The second and third abstractions are sources and sinks. Sources provide natural resources that we can transform into capital to sustain the economy, and sinks absorb the waste or pollution produced by the system. Elements in the system can act as sources and sink – for instance, tree produce wood and do absorb some CO2.
  • The fourth abstraction is that of limits. Sources and sinks have limits, which constrain how much can be provided or absorbed. A limit can be absolute, constraining the finite amount in the world, or a rate, constraining how much can be produced or absorded in a certain time.

You can tune various parameter in the model to compute scenarios about the future. And that’s what they do in the book.

The first scenario is the utopia scenario without limits. In this scenario, growth continues indefinitively and the civilization prospers beyond 2100. The other scenarios are scenario with limits in place and various assumptions about the rate of progress and global policies.

And here is the bad news. In these scenarios, growth tends to stop in the second half of the century which leads to a collapse with population decline. These scenario are no forecast. They only oultine possible trajectories and trends. Unfortunately, no matter how we tune the model, as soon as we re-introduce limits, the collapse trend is clear.

This is also the case for ecomodernism scenarios. There’s a whole chapter in the book explaining why technological progress and market alone, even with ideal parameters, won’t suffice.

Several such scenario lead to collapse due the lag time between reaction and problem. We are dealing with cycles that happen over decades. It takes decades for pollution to disseminate from production site to environment; it takes decades to engineer new technologies; it takes decades to renew or replace existing infrastructure. When the reaction comes, it’s too late. The most optimist scenario (scenario 6) of this category seem to almost achieve sustainability, but ultimately collapse too due to pressure on the system and the cost of technology required for it.

This book is a fascinating analysis, even if the perspective is grim.

In all the scenarios, the same model is used as well as the same limits (except for the scenario without limit). We could of course explore a lot more scenarios, with modifications in the model or of the limits. I’m sure the authors did. But the model and these limits reflect what the authors think approximates best reality. Finding solutions for an alternate reality doesn’t help. But it’s a model after all, so there’s room for critique of the results. And for hope.

What I would have found interesting but isn’t in the book, is a “backward” analysis of how much rate of progress assuming these limits would be needed to achieve true sustainablility. If 2020 told us anything with the pandemic, it’s that if pressure is there, progress can sometimes happen fast.

The story of the ozone hole acts in the book as a case study of a real-world feedback loop with long delay. This story is hopeful, even if unclear how we could replicate such success for other areas. In the last chapter, the authors make a call for a next revolution after the industrial revolution – the sustainability revolution. I like the idea, but wished that the learnings of the ozone story would have been transformed in more concrete inputs in this chapter.

This book left me a better understanding of:

  • Delays in feedback loops
  • The risk of ecomodernism
  • The role of land/food in growth
  • Systems thinking
  • The ozone hole

On top if all that, I’m very impressed that the first version of the book was written in the 70s. 50 years later we only start to believe what they were saying because we start to see it for real (seeing is believing), not because we’ve become more clever.

MORE

“The scientific message of LtGgot lost in the turmoil of the pop-ular debate. Global society is likely to overshoot, said LtG,andthen be forced to decline or collapse – because of significant re-action delays in the global economy. These are the lags in the per -ception and localization of global limits, the significant institu-tional delays involved in (democratic) decision making, and thebiophysical lags between implementation of remedial action andthe improvement of the ecosystem. The real message was appar -ently never picked up by anyone, neither critic or fan.

…

But as con-traction does not occur in the model system until around 2020,historical comparison up to 2010 does not give much guidanceabout the veracity of the contraction part of the LtGbusiness asusual scenario. By 2030, we will have a much clearer answer tothat question.”

Energy and Civilization

The book Energy and Civilization, from Vaclav Smil, looks at the history of civilizations through the lense of energy: how did the methods to store and transform energy change over time?

Almost all aspects of a society can be linked back, directly or indirectly, to energy. At the lowest level we need energy, as food, to sustain our metabolism. For centuries, society has been organized in a relatively straightforward manner around food production. Transformation of society happened out of necessity, to scale to larger population. The role of society is, in a way, to organise the transfer, transformation, or production of energy for our needs. In the case of modern society, this organization can be very complex. Natural resources are transformed using energy into products that are stored, exchanged, and used to transform other resources into products.

I don’t recall Vaclav Smil from every using the word “recursive” in the book, but coming from computer science, the flow of energy through society felt to me this way. We transform energy into heat, light, or motion in a recursive scheme.

The book covers all major energy transitions in great details. From hunter-gatherer to agriculture with animals and water wheels/windmills, from agriculture to stream engines and coal, from steam engines to combustion engines and electricity, and from combustion engine to renewable energy. Nuclear is of course discussed, too. Using this perspective, the industrial revolution spans several energy transitions.

The total cost in energy of a method or process can only be computed if we consider the “recursive” steps too. The horse you use to improve farming also need to be fed. Solar cells must be produced first, before they in turn generate energy. The book covers many analysis of such total costs.

Over the centuries, methods to transform energy – be it with animals like draft horse, or tools and machines like water wheels, steam engine, or coal furnace – have been improved to reduce energy waste. The book makes a great account of the improvements.

To get a sense of the depth of detail, consider that the book contains for instance a comparison of the efficiency of the various water wheels; or a description of the various tools used for farming; or an analysis of the shock on the twin towers on 9/11 in terms of energy. The book is this level deep of details.

The reading isn’t always easy and the book needs some perserverance. But this depth has its reward too, in that it’s a great documentation of human ingenuity.

Going in length to describe the various uses of energy, the book often contrast them with human labor. This made me more appreciative of the incredible power of the many tools and machines we use. Tools and machines at our disposal enable one person to achieve tasks where hundred or more people would have been required before the industrial revolution.

The book is quite short when it comes to the future. It surprised me, but we can’t fault the book for this. After all, the book is titled “Energy and Civilization: a History”, not “Energy and Civilization: an Outlook”.

Like many readers, I bought the book because it was on Bill Gates recommendations (here’s also his review of the book). While I don’t consider the book a must read, I’m thankful of Bill, since the book taught me a good deal about:

  • The various types of energy stores (coal, biomass, nuclear, wood, etc.) and transformations
  • The energy transitions and their timescale (centuries!)
  • How energy flows in society
  • The energy that modern life requires and its contrast with human labor
  • The ingenuity of mankind to transform energy efficiently
  • The challenges ahead of us to transition to renewables