@@ -0,0 +1,800 @@ | |||
<!doctype html><!-- This is a valid HTML5 document. --> | |||
<!-- Screen readers, SEO, extensions and so on. --> | |||
<html lang="fr"> | |||
<!-- Has to be within the first 1024 bytes, hence before the `title` element | |||
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
<meta charset="utf-8"> | |||
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
<!-- The viewport meta is quite crowded and we are responsible for that. | |||
See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
<meta name="viewport" content="width=device-width,initial-scale=1"> | |||
<!-- Required to make a valid HTML5 document. --> | |||
<title>Permacomputing Update 2021 (archive) — David Larlet</title> | |||
<meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
<!-- That good ol' feed, subscribe :). --> | |||
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
<!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
<link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
<meta name="msapplication-TileColor" content="#f7f7f7"> | |||
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)"> | |||
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)"> | |||
<!-- Documented, feel free to shoot an email. --> | |||
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css"> | |||
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
<script> | |||
function toggleTheme(themeName) { | |||
document.documentElement.classList.toggle( | |||
'forced-dark', | |||
themeName === 'dark' | |||
) | |||
document.documentElement.classList.toggle( | |||
'forced-light', | |||
themeName === 'light' | |||
) | |||
} | |||
const selectedTheme = localStorage.getItem('theme') | |||
if (selectedTheme !== 'undefined') { | |||
toggleTheme(selectedTheme) | |||
} | |||
</script> | |||
<meta name="robots" content="noindex, nofollow"> | |||
<meta content="origin-when-cross-origin" name="referrer"> | |||
<!-- Canonical URL for SEO purposes --> | |||
<link rel="canonical" href="http://viznut.fi/texts-en/permacomputing_update_2021.html"> | |||
<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all"> | |||
<article> | |||
<header> | |||
<h1>Permacomputing Update 2021</h1> | |||
</header> | |||
<nav> | |||
<p class="center"> | |||
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use> | |||
</svg> Accueil</a> • | |||
<a href="http://viznut.fi/texts-en/permacomputing_update_2021.html" title="Lien vers le contenu original">Source originale</a> | |||
</p> | |||
</nav> | |||
<hr> | |||
<p>It is now more than a year since I wrote <a href="http://viznut.fi/texts-en/permacomputing.html">my "early notes" about | |||
Permacomputing</a>. At that time, I was not yet aware of anyone else having | |||
similar ideas, so I've now decided to write an update that connects my ideas | |||
with the existing discussions and activities. I also want to share some new | |||
ideas I have been pondering about. This text is about 33K characters / 4900 | |||
words long, so allocate your time accordingly.</p> | |||
<h2>1. A fragmented pluriverse</h2> | |||
<p>The "biosphere-aware computing scene" is quite fragmented. There are many | |||
different islands (groups and individuals) that use different terminology | |||
and that are only now discovering each other. It is therefore important to | |||
build bridges between the islands.</p> | |||
<p><a href="https://computingwithinlimits.org/">Computing within Limits | |||
workshops</a> that started in 2015 form an important hub but have been | |||
rather invisible from non-academic perspectives. Many interesting papers | |||
have come out of these workshops, but I would really like to see more | |||
practical and/or longer-term projects that go beyond the shortish workshop | |||
papers. Computing within Limits branched out of a larger field of | |||
"sustainable" ITC <a href="http://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-375131">that is known | |||
to have huge problems</a>.</p> | |||
<p>Another hub is in the <a href="https://en.wikipedia.org/wiki/Fediverse">Fediverse</a>, particularly | |||
around the Mastodon server <a href="https://merveilles.town/">Merveilles.town</a> that centers around | |||
creativity and sustainable technology. Many of these productive hackers, | |||
artists and activists also participate in the "smolnet"/"smallnet", | |||
including the space of the <a href="https://gemini.circumlunar.space/">Gemini</a> protocol. My | |||
Permacomputing article was very well received in these circles and many have | |||
adopted the concept for their use.</p> | |||
<p>Then there's the "Sustainable Internet" activism that has the <a href="https://branch.climateaction.tech/about">Branch online magazine</a>. I | |||
tend to lump this together with the various "solar web" projects such as the | |||
<a href="https://www.lowtechmagazine.com/2020/01/how-sustainable-is-a-solar-powered-website.html">solar-powered | |||
version of Low-Tech Magazine</a> and the <a href="http://solarprotocol.net/">Solar Protocol</a>. Also somewhat related | |||
is the <a href="https://smallfile.ca/">Small File Media Festival</a> that | |||
criticizes the carbon footprint of streamed media with smallish (video) | |||
files. This is an area where the demoscene could make important | |||
contributions.</p> | |||
<p>In addition to the generic groups of like-minded people, there are | |||
specific projects, such as <a href="https://collapseos.org/">Collapse | |||
OS</a>, whose participants don't necessarily have connections to wider | |||
groups.</p> | |||
<p>Occasionally, an online article pops up that expresses similar concerns | |||
and ideas as I did with the Permacomputing essay, like Wim Vanderbauwhede's | |||
<a href="https://wimvanderbauwhede.github.io/articles/frugal-computing/">Frugal | |||
computing</a>. It is great to see that many different people independently | |||
come to similar conclusions, but this can also be seen as a sign that we | |||
need more social media activism and awareness-rising even to make all the | |||
concerned people find each other.</p> | |||
<p>Marloes de Valk has been <a href="https://computingwithinlimits.org/2021/papers/limits21-devalk.pdf">mapping</a> | |||
this scattered "pluriverse" and its terminology, but I have the feeling that | |||
this only scratches the surface, and that there's a lot of relevant practice | |||
going on in e.g. non-Western countries.</p> | |||
<p>A major problem with this "pluriverse" is the lack of a common name to be | |||
used in communication. "Permacomputing" scored quite high in De Valk's | |||
Fediverse poll, and I have no objections against using it for this purpose. | |||
Something like "radically sustainable computing" might also be a good | |||
umbrella term ("radically" being the keyword that differentiates it from the | |||
greenwashed capitalism of "Sustainable ITC").</p> | |||
<h2>2. Collapse Informatics</h2> | |||
<p>Many of the early Computing within Limits papers discuss collapse and | |||
scarcity scenarios from somewhat bleak viewpoints. In later years, the | |||
research community started to reframe itself in more positive ways by | |||
drawing inspiration from e.g. Hes & du Plessis' <i><a href="https://www.routledge.com/Designing-for-Hope-Pathways-to-Regenerative-Sustainability/Hes-Plessis/p/book/9781138800625">Regenerative | |||
Sustainability</a></i> and Escobar's <i><a href="https://www.dukeupress.edu/designs-for-the-pluriverse/">Designs for | |||
the Pluriverse</a></i> – just like Permacomputing draws inspiration from | |||
Permaculture. But even when focusing on a positive vision, one should not | |||
take anything for granted. If a vision cannot survive a collapse of | |||
industrial production or network infrastructure, it isn't resilient | |||
enough.</p> | |||
<p>An important paper in the collapse vein is Jang et al.'s <i><a href="https://kurti.sh/pubs/unplanned_limits17.pdf">Unplanned Obsolescence: | |||
Hardware and Software After Collapse</a></i> that e.g. estimates lifetimes for | |||
various hardware components, with the conclusion that it may be possible to | |||
maintain some of current computer hardware for several human generations | |||
even if the entire semiconductor industry collapsed right now. Solderpunk | |||
(the creator of the afore-mentioned Gemini) has a concrete proposal for a | |||
"<a href="gopher://zaibatsu.circumlunar.space/0/%7esolderpunk/phlog/the-standard-salvaged-computing-platform.txt">standard | |||
salvaged computing platform</a>" based on smartphone/tablet e-waste. I'm | |||
sure that there are components with much longer potential lifespans (Jang et | |||
al. estimate current mobile hardware to be able to persist for about one | |||
generation), but at least there would be heaps of this type of junk | |||
available in the early years. I'm personally interested by the possibilities | |||
of microcontroller-based smartcards (that are even more ubiquitous than | |||
mobile phones but have entirely different challenges).</p> | |||
<p>Jang et al. also have a few interesting words about maintenance culture. | |||
In the same way as religious organizations continued to maintain ancient | |||
Chinese roads that no longer received governmental support, computing could | |||
be maintained in a post-collapse world by "semi-ascetic cultural | |||
organizations whose primary focus may or may not be computing". I have | |||
personally been fascinated by the potential of monastery-like communities to | |||
preserve science and technology even during "dark ages" when the society at | |||
large sees no value in them. In medieval Europe, some monasteries even | |||
refined and advocated technologies such as <a href="https://www.researchgate.net/publication/271064820_Wind_and_Water_in_the_Middle_Ages_Fluid_Technologies_from_Antiquity_to_the_Renaissance">water | |||
power</a>.</p> | |||
<p>The term <i><a href="https://www.researchgate.net/publication/262276832_Collapse_Informatics_and_Practice_Theory_Method_and_Design">collapse | |||
informatics</a></i> comes from Bill Tomlinson who suggests that one should look | |||
into the existing computing practices in groups that have voluntarily chosen | |||
to live off-grid or in other "collapse-like" conditions. I might also want | |||
to include those who do so involuntarily, as well as those who have made | |||
"collapse-compatible" decisions specifically with computing (e.g. artists | |||
who specialize in old hardware).</p> | |||
<p>I don't know if there is going to be a collapse, but I'm quite sure that | |||
the entire society needs to reduce energy consumption, lengthen | |||
technological lifespans and reduce superfluous dependencies. Recognizing the | |||
possiblity of a collapse may help coordinate these changes. <i><a href="https://www.ceguide.org/Strategies-and-examples/Design/Design-for-disassembly-deconstruction">Designing for | |||
disassembly</a></i> is an example of a concrete goal that supports hardware | |||
longevity in both collapse and non-collapse scenarios.</p> | |||
<h2>3. Anti-utilitarianism</h2> | |||
<p>In profit-oriented societies, people often try to make themselves and | |||
their fields of expertise as important and useful as possible. It has | |||
therefore been delightful to learn about visions that detach computing from | |||
all utilitarian purposes.</p> | |||
<p>Brendan Howell's <i><a href="https://moddr.net/rustic-computing/">Rustic | |||
Computing</a></i> is an artistic project that depicts computing as "the pastime | |||
of dilettantes, amateur scientists and gentleman tabulators who construct | |||
machines to manipulate abstract symbols with no practical application". | |||
Computer components are built using pre-industrial technology, which reminds | |||
me of early mechanical computers such as Zuse's Z1. When computers are built | |||
with non-pollutive technologies, they don't need to justify their existence | |||
by paying back their ecological debts. And since they have no practical | |||
purpose, they don't even have to be faster or better than manual | |||
paper-and-pencil calculation. They can just be interesting and important the | |||
way they are.</p> | |||
<p>I see much of the same attitude in <i><a href="https://compudanzas.net/about.html">Compudanzas</a></i>, a research | |||
project that reimagines computing in the form of "seemingly useless" | |||
activities such as rituals and dancing.</p> | |||
<p>In Steve Lord's idea of <i><a href="https://thedorkweb.substack.com/p/the-100-year-computer">Heirloom | |||
Computing</a></i>, a computer that has been made to last for many generations | |||
can be a piece of family history that evolves with the family, keeping | |||
permanent traces from every generation that has used it, and does not need | |||
to have any purpose besides this.</p> | |||
<p>As suggested by Jang et al., a post-collapse society that has eventually | |||
lost all of its artificial computing capacity may still want to continue the | |||
practice of computer science in a purely theoretical level, as a form of | |||
mathematics. This is another example of how computing may remain meaningful | |||
for some pockets of culture even with no ability to run any potential | |||
applications.</p> | |||
<p>Detachment from utilitarism may (perhaps paradoxically) give way to a | |||
deeper importance and meaning. I'm particularly thinking about Yuk Hui's | |||
idea of <i><a href="https://www.academia.edu/35561477/On_Cosmotechnics_For_a_Renewed_Relation_between_Technology_and_Nature_in_the_Anthropocene">Cosmotechnics</a></i> | |||
which refers to a unified harmony between technology, culture and non-human | |||
nature. Modern technological thinking lost this harmony by turning | |||
everything into utilitarian resources. An interesting point made by Hui is | |||
that every culture should find its own approach to cosmotechnics – so, we | |||
would be replacing a homogenous global utilitarian monoculture with a rich | |||
and diverse polyculture.</p> | |||
<h2>4. Limits of imagination</h2> | |||
<p>It is often difficult to even imagine a kind of computer culture that | |||
does not suffer from unlimited growth. Even the most interesting real-world | |||
examples (such as the Soviet computing culture) exist somewhat in the shadow | |||
of Western developments and ideologies. So, there's no real "other" to | |||
contrast the growth-obsessed mainstream computing with.</p> | |||
<p>Computing within Limits papers have also given me an impression that some | |||
scholars even find it difficult to imagine e.g. how software development | |||
could take place without the Internet. In cases like this, I might suggest | |||
looking into the actual history and listening to people who have experienced | |||
it. Even though the history of computing isn't nearly as diverse as it could | |||
or should be, it is still worthwhile to study it. And definitely not only | |||
the mainstream "winners' history" but everything from the various cultures | |||
and subcultures.</p> | |||
<p>Eriksson and Pargman <a href="https://computingwithinlimits.org/2018/papers/limits18-eriksson.pdf">have | |||
suggested the use of counterfactual history</a> to assist imagination. | |||
Sadly, their own <i><a href="https://www.researchgate.net/project/Coalworld">Coalworld</a></i> | |||
scenario (with the point of divergence being an early-seventies "peak oil" | |||
event) has not yet reached the point where computing can be elaborated. I | |||
wish there was more speculation (both fiction-oriented and academically | |||
rigorous works) that would present thoroughly-imagined alternatives to the | |||
actual history.</p> | |||
<h2>5. Alternative paradigms</h2> | |||
<p>I've already mentioned several "alternative paradigms of computing": | |||
<i>frugal computing</i>, <i>heirloom computing</i>, <i>rustic computing</i>, | |||
<i>collapse informatics</i>. But there are still a few more to add:</p> | |||
<p><i><a href="https://computingwithinlimits.org/2018/papers/limits18-mann.pdf">Regenerative | |||
computing</a></i> is Mann et al.'s idea of applying Hes & du Plessis' | |||
<i>Regenerative sustainability</i> to computing. The most | |||
Permacomputing-relevant part of the Limits'18 is quite dense, so I'll quote | |||
it verbatim: (number 7 refers to Hes & du Plessis' 2014 book <i><a href="https://www.routledge.com/Designing-for-Hope-Pathways-to-Regenerative-Sustainability/Hes-Plessis/p/book/9781138800625">Designing | |||
for hope: pathways to regenerative sustainability</a></i>)</p> | |||
<blockquote> | |||
(3) Move beyond efficiency as the primary lever available to computing. - | |||
These new narratives should look to nature and ecology to demonstrate the | |||
interplay between computing, society and biological systems where limits of | |||
these systems are respected and worked with.<br> | |||
(4) Integrate ecological worldviews into computing's narratives and | |||
processes both the theory such as living systems and deep ecology, and | |||
values sets: | |||
<ul> | |||
<li>Integrity - maintaining the wholeness of [wider] systems, ensuring that | |||
structure and relationships remain intact and functioning as they | |||
should.</li> | |||
<li>Inclusivity - "interacting with the world in its entirety" [7, p. 35], | |||
engaging and integrating with all dimensions, levels of existence and | |||
knowledge.</li> | |||
<li>Harmony - all elements cooperate through relationships that are | |||
respectful in order to avoid dissonance.</li> | |||
<li>Respect - all parts of the world have intrinsic worth and all existence | |||
is part of the extended self, and therefore all self-respect is extended to | |||
mutual respect for the world.</li> | |||
<li>Mutuality - "we are in this together, and what happens to ‘others’ will | |||
also have an effect on self" - see: compassion, treating others the same as | |||
yourself.</li> | |||
<li>Positive reciprocity - "reciprocating in a way that is | |||
of benefit to and advances the relationship between | |||
self and extended self" [7, p. 35].</li> | |||
<li>Fellowship - an extension of mutuality and positive reciprocity, where | |||
the world is co-created by humans in partnership with nature.</li> | |||
<li>Responsibility - morally accountability for the consequences of our | |||
actions in an uncertain and unpredictable world</li> | |||
<li>Humility - change is constant, we cannot know the true consequences of | |||
our actions</li> | |||
<li>Non-attachment - In order to adapt to changing circumstances it is | |||
important to uphold non-attachment in order to decouple from “the futility | |||
of trying to hold onto anything in an ever changing world including ideas, | |||
dogmas and strategies” [7, p. 36]</li> | |||
</ul> | |||
</blockquote> | |||
<p><i>Convivial computing</i>, from <a href="https://www.researchgate.net/publication/235173004_Constrained_Design_Processes_Steps_Towards_Convivial_Computing">Fischer | |||
& Lemke's 1987 paper</a>, is an earlier example of taking ideas from | |||
ecologically conscious thinking into computing (in this case, from Ivan | |||
Illich's book <i>Tools for Conviviality</i>). Even earlier, Lee Felsenstein | |||
had been inspired by the same book when designing the Osborne 1 personal | |||
computer. In both cases, however, the ecological aspects of Illich's thought | |||
are ignored. Also, Fischer & Lemke's paper doesn't feel at all like a | |||
forgotten masterpiece of groundbreaking thought – the ideas actually seem to | |||
be very much in line with what was implemented in the "<a href="https://en.wikipedia.org/wiki/Rapid_application_development">RAD</a> | |||
tools" of the 1990s. And some of these tools (Delphi, Visual Basic) felt | |||
like the epitome of bloat at the time.</p> | |||
<p><i><a href="https://computingwithinlimits.org/2015/papers/limits2015-raghavan.pdf">Benign | |||
computing</a></i> basically advocates keeping things small in order to keep | |||
the problems caused by them small. Currently, huge problems are created by | |||
huge, centrally-managed systems built with the principles of abstraction and | |||
indirection. Raghavan's critique of these principles is very similar to how | |||
I see "<a href="http://viznut.fi/texts-en/maximalism_virtualism.html">maximalism and | |||
virtualism</a>". I also completely agree with Raghavan about that "the | |||
utopian notion of creating new technology that is strictly "beneficial" or | |||
that advances "development"" must be rejected.</p> | |||
<h2>6. Permacomputing practice</h2> | |||
<p>My Permacomputing article from 2020 is basically a vision of a new kind | |||
of computing that works in a radically different way in a radically | |||
different society. It does not give many guidelines towards actual practice | |||
or how to transition towards permacomputing, so maybe I should cover this | |||
area a little bit.</p> | |||
<p>I have been reluctant to name specific technologies or design constraints | |||
for permacomputing. This is because I want to support a diverse polyculture | |||
of ideas and possibilities. Asking what is the most suitable programming | |||
language for permacomputing is a bit like asking what is the most suitable | |||
plant for permaculture – the entire question contradicts itself. There is no | |||
"silver bullet" – there isn't one even in the mainstream industry despite | |||
its continuous attempts to uniformize everything. However, there can be | |||
design wisdom about the strengths, weaknesses and mutual interactions of | |||
specific elements, and this wisdom helps with choosing a language, a plant, | |||
an algorithm or a design pattern for a specific place.</p> | |||
<p>In software, nothing that can be run locally is "poisonous" per se. Even | |||
if something consumes a lot of energy, it does not need to mean more than | |||
that the consumption must be restricted to when that energy is available. | |||
Far more important questions are how the hardware is obtained and | |||
maintained, and how the energy is produced.</p> | |||
<p>I have noticed that many "sustainable" or even "low-tech" computing | |||
projects have been built on cheap DIY-oriented boards such as Raspberry Pi. | |||
Even though these may be among the best of the currently available options, | |||
it should be noted that they have been designed for hackability and | |||
replaceability rather than longevity or repairability. There might be a need | |||
for a radically repairable and modifiable hardware basis to fulfill similar | |||
purposes. Radical modifiability might include the ability to interface with | |||
a large variety of different chips (processors, SoCs etc.) – this would help | |||
maximize the usable lifespans of those chips.</p> | |||
<h3>6.1. Low complexity</h3> | |||
<p>Keeping systems very simple but very capable is a good guideline for a | |||
lot of permacomputing, but particularly so for the crucial basic software | |||
used to enable salvaged/makeshift hardware. Bare-hardware Forth systems | |||
(such as Collapse OS or OpenBIOS) are very capable for their low complexity, | |||
and can be small enough even for rudimentary 8-bit microcontrollers.</p> | |||
<p>One possible approach to simplicity is to try to keep things simple | |||
enough that they can be thoroughly understood and (re)implemented by one | |||
person. This applies not only to application programs but the dependent | |||
elements as well (programming language, operating system, firmware, | |||
hardware). This is not to say that people should write everything from | |||
scratch but to keep the complexity human-graspable. The ideal of human-sized | |||
computing is particularly applicable to systems that are used as tools | |||
(because tools in general should be thoroughly understandable to their | |||
users). Also, in decentralized "post-collapse" societies, the local | |||
all-around experts ("village hackers") should be able to master all aspects | |||
of the local computing systems in order to maintain them and to adapt them | |||
to various local needs. All this becomes much easier if complexities are | |||
kept low or moderate.</p> | |||
<p>The effective complexity of a software program can be estimated by | |||
summing its executable size with the size of the minimum set of dependencies | |||
required to run it (including the OS components). Alternatively, one can | |||
calculate its bootstrap complexity (by summing the size of all code and data | |||
required to compile the program, the dependencies, and the entire dependency | |||
network of the toolset required for the compilation in the smallest system | |||
that can run them). These types of assessment strongly favor programs that | |||
are written in non-bloated languages and can be made run on bare hardware – | |||
even if they can also run in bloated environments and use their special | |||
features.</p> | |||
<p>One way to deal with huge platforms is to create "pockets of simplicity" | |||
such as <a href="https://100r.co/site/uxn.html">simple virtual machines</a> | |||
that can also run on bare hardware. Emulators of existing hardware platforms | |||
are a special case of this. VMs are particularly suitable for small things | |||
that require far less computation than what the hardware is capable of. A | |||
virtual machine may also help eliminate compatibility problems and code rot, | |||
if it is unambiguously defined and the definition is canonized (permanently | |||
frozen). If approached with mainstream engineering attitudes, however, VMs | |||
may easily lead to "Java-like" problems (wastefulness, incompatibilities, | |||
etc.) Setting artificial limits to memory usage and execution speeds may | |||
prevent some of these developments. One might also want to think about how | |||
to statically translate VM programs into native code for running on | |||
platforms that are actually small.</p> | |||
<p>In mainstream computing, "ease of use" is usually implemented as | |||
"superficial simplicity" or "pseudo-simplicity", i.e. as an additional layer | |||
of complexity that hides the underlying layers. Meanwhile, systems that are | |||
actually very simple and elegant are often presented in ways that make them | |||
look complex to laypeople (think about the esoteric syntax of Forth or Lisp, | |||
for example). Ideally, UIs should reflect, amplify and illustrate the | |||
underlying elegance instead of trying to hide or misrepresent the inner | |||
workings. The earliest versions of the Apple Macintosh OS manage to do this | |||
to some extent (the system is not much more complex than the UI | |||
representation, every file is represented by an icon, program files are | |||
stand-alone without external dependencies, etc.)</p> | |||
<p>When minimizing the internal complexity of a system, however, it should | |||
not be isolated from the complexity of the external world. Computers are | |||
dependent on energy availability, temperature and other conditions, so they | |||
should be able to adjust their operation to the changes in these conditions | |||
– even if environmental monitoring is not among their designated tasks.</p> | |||
<h3>6.2. Towards concrete examples</h3> | |||
<p>Permacomputing has so far been defined in ways that emphasize generic | |||
ideas and a wide diversity of possibilities. However, in order to actually | |||
create something that represents permacomputing, one needs to make a lot of | |||
specific design decisions. Concrete examples (either real projects or | |||
mockups) may help with this. In order to cover the possibility space, we | |||
need a lot of different examples from different points of view.</p> | |||
<p>One possible starting point is to think about a general-purpose | |||
single-user computer that remains usable and relevant as long as possible | |||
even in a collapse scenario. Of course, any computer should be | |||
end-user-programmable and have some kind of programming interface to | |||
facilitate it, but what would be the concrete applications this kind of | |||
computer would be used for?</p> | |||
<p>I assume that viewing text files from physical storage devices (such as | |||
flash memory) is what would persist the longest in any scenario. A few | |||
gigabytes of storage would be enough for an entire library of literature | |||
that could be valuable for centuries. And accessing it would be possible | |||
(although not comfortable) even with very rudimentary post-collapse I/O | |||
devices (such as a few switches and indicators for a manual serial protocol | |||
– somewhat like using a Morse code telegraph).</p> | |||
<p>It may be theoretically possible to even read data directly from a USB | |||
flash drive with this kind of manual "telegraphy", but the complexity of the | |||
USB protocol would probably get overwhelming. Fortunately, a complex | |||
protocol implies that there is a (re)programmable microcontroller in the | |||
device, so one may want to reprogram it to support a simpler protocol. One | |||
could also add a "backdoor" that enables the device to run arbitrary | |||
programs from the drive, thus unleashing its potential for general-purpose | |||
computing. It may even be possible to get a USB stick to drive "proper" | |||
interface devices such as display screens despite the low number of I/O pins | |||
(two output pins are enough for composite video, but LCD panels | |||
unfortunately tend to need much more, so some kind of a multiplexer would be | |||
required). This could help reduce and postpone the need for "Morse | |||
code".</p> | |||
<p>These could become general guidelines for maximizing the lifespans of | |||
arbitrary programmable devices: 1) make it as straightforward as possible to | |||
run arbitrary code, 2) support an electrically simple interface that can | |||
even be operated manually in times of far-future scarcity.</p> | |||
<p>Another persistent application besides file viewing would be text | |||
editing. It has been prominent in personal computers since the early years | |||
and probably will be in just about any scenario. It would also imply the | |||
need for general file management tasks such as copying files between storage | |||
devices. Programs for doing these tasks would be among the first to | |||
implement for any "permacomputer" that does not require special expertise to | |||
use.</p> | |||
<p>Telecommunication is important but does not require computers – messages | |||
may well be relayed with classical amateur radio methods. Also, computer | |||
file-sharing networks can well be based on physical media. However, the | |||
existence of a radio and a computer makes it appealing to combine the two. A | |||
program for transferring files and text streams over abritrary channels, in | |||
one- or two-way protocols or packet protocols, with or without error | |||
correction and/or encryption, would be a fine inclusion to the set of | |||
"collapse software".</p> | |||
<p>Of course, supporting far-future post-collapse scenarios does not mean | |||
that one should stick to far-future post-collapse practices – rather, it | |||
ensures that there are fallbacks for everything. You can use a | |||
high-resolution screen today, but the system will work fine even with | |||
tomorrow's more rudimentary display. You can run a complex OS today, but the | |||
simple OS in the firmware ROM is also perfectly fine for editing a text | |||
document.</p> | |||
<p>I imagine that this "simple OS" would normally look either like a plain | |||
Forth interpreter or an orthodox file manager (i.e. a Norton Commander | |||
clone), depending on whether the computer is connected to a sufficient | |||
screen or not. For screens that are a bit too small for the OFM there might | |||
also be an intermediate option that resembles early-2000s cellphone | |||
interfaces. All of these modes would be usable even with quirky input | |||
devices (such as a game controller, a single telegraph key or a barely | |||
functional touchscreen). Hardware is accessed via Forth words that can be | |||
straightforwardly redefined if there are unexpected hardware changes (such | |||
as specific glitches that need to be bypassed).</p> | |||
<p>The OFM would allow one to browse, view and manipulate files, run | |||
executable files, edit text files and enter Forth commands. It could also be | |||
set up as a bootloader to load a more complex OS, but loading one would | |||
often be unnecessary, as many programs (especially ones that favor | |||
single-tasking) would also be available as "Forth" executables (that may | |||
also be native binaries that may or may not use Forth words) or as "ROM" | |||
files runnable with a simple VM.</p> | |||
<p>Systems that don't have much capacity to spare would perhaps only have a | |||
plain Forth interpreter, or if even that would be too bloated, something | |||
like the standard byte protocol used by smartcards.</p> | |||
<p>Longevity maximization easily leads to an emphasis on conservative and | |||
well-tested ideas, so this example may sound a little bit bleak. A fancier | |||
starting point (such as one based on ideas from unconventional computing) | |||
would perhaps give more room for fancier permacomputing ideas that take more | |||
distance from fossil-era computing.</p> | |||
<h3>6.3. Sustainable cyberspace</h3> | |||
<p>There are many projects that address the sustainability problems of the | |||
World Wide Web. Activism for sustainable websites, solar-powered servers, | |||
new protocols, simpler document formats. However, these often take the | |||
underlying Internet for granted. The access may perhaps be slow at times or | |||
places, and a solar-powered server may be sometimes offline, but any place | |||
of the world is still supposedly accessible from any other place of the | |||
world at any time. The weirdness of this assumption may not even be obvious | |||
to modern Internet users – after all, it is in the core of nearly every | |||
major service/protocol (perhaps apart from Email and Usenet that can also | |||
propagate over temporary connections).</p> | |||
<p>I see need for a decentralized protocol that works painlessly in | |||
conditions where everything is not constantly available. Where individual | |||
servers or communication links may be online or offline depending on | |||
circumstances. Where other parts of the network may only be accessible via | |||
temporary connections, physical file-sharing or data mules. Where your | |||
messages still reach their destinations, where you still get the files you | |||
need, and where "social media" discussions can still thrive, despite all | |||
these logistical constraints.</p> | |||
<p>For some inspiration for the required mindset, one may think about how | |||
files were collected and propagated in "pre-Internet" conditions (BBSes, | |||
friend-to-friend file copying) and how to make these processes as automatic | |||
as possible.</p> | |||
<h2>7. Collapse-tolerant business</h2> | |||
<p>I don't often think about how to do business in the capitalist economy, | |||
but in the early 2021 I asked myself what kind of IT company (or other type | |||
of IT-related organization) would thrive both before and after a collapse. I | |||
wanted to challenge my prejudice that anything you do for profit/living will | |||
always be somewhat "greenwashed" instead of properly sustainable.</p> | |||
<p>Here are my ideas of how a relatively small "permacomputing company" | |||
could operate in the "age of abundance":</p> | |||
<ul> | |||
<li>Accept software-related and other customer projects just like any | |||
average IT company, as long as they are in line with strict eco-ethical | |||
standards. Refuse to contribute to the wasteful use of resources, and | |||
strongly prefer doing things in sustainable and robust ways. Make these | |||
standards a part of the company brand.</li> | |||
<li>Have long-term in-house research and development projects related to | |||
radically sustainable computing, both software and hardware. Convince | |||
investors about their vitality to the future of civilization. Also practice | |||
permaculture (or constantly co-operate with ones who do) and try to connect | |||
it to everything else that the company is doing.</li> | |||
<li>Self-host everything you need for software work on local physical | |||
servers. This includes all networked applications as well as an extensive | |||
library of software and documentation (including repair manuals and OS | |||
distributions for all relevant hardware). Offer hosting services to make | |||
use of the surplus.</li> | |||
<li>Produce as much of your own energy as possible with solar panels, wind | |||
turbines etc. Sell the surplus to the company that maintains the grid.</li> | |||
<li>Repair and maintain all hardware by yourself. Maintain a storage | |||
facility for old/recycled hardware. Offer services related to repairing and | |||
recycling (in a small scale, for now). Maintain a hackerspace or constantly | |||
co-operate with one.</li> | |||
<li>Support forms of culture that strengthen the status of radically | |||
sustainable computing/technology (e.g. hackerspaces, education, demoscene | |||
events, art projects that use "obsolete" hardware, etc.)</li> | |||
<li>Make sure that many of the employees live close to the office. Maintain | |||
spaces that can be turned into apartments once transportation becomes more | |||
difficult.</li> | |||
</ul> | |||
<p>Once the world has completely changed, the focus or the organization will | |||
become somewhat wider: | |||
</p> | |||
<ul> | |||
<li>Accept any customer projects related to computing or any other | |||
technology you happen to understand. Offer repair services.</li> | |||
<li>Collect/buy "e-waste", build working computers and appliances out of it, | |||
sell them.</li> | |||
<li>Keep in contact with the rest of the "computing scene" even if | |||
long-range communication networks have collapsed. Share information and | |||
trade hardware components. Use couriers if necessary.</li> | |||
<li>If microchips or some other essential components are no longer produced, | |||
participate in attempts to restart the production (in a small scale, for | |||
now – until we learn how to do it sustainably).</li> | |||
<li>Similarly, try to rebuild communication networks if they have collapsed. | |||
Offer communications services, maybe maintain "Internet cafés".</li> | |||
<li>Maintain digital and physical libraries of pre-collapse and | |||
post-collapse information. Print physical books. Participate in projects | |||
that support the continuing existence of science and education.</li> | |||
<li>Make sure that technological understanding will pass on to new | |||
generations. If necessary, educate the new employees (or cult members or | |||
whatever they may be called) from scratch.</li> | |||
<li>If it becomes impossible to make living out of this, start depending on | |||
agriculture. But in any case don't forget the importance of science and | |||
technology. If necessary, explain the importance in religious terms.</li> | |||
</ul> | |||
<h2>8. Postdigital advocacy</h2> | |||
<p>Art researchers recognize the concept of "postdigital" as a reaction | |||
against the so-called "digital revolution" that took place in the nineties, | |||
and especially against the typically "digital" esthetics. Using cassette | |||
tapes for music in a world where digital music formats are ubiquitous is an | |||
obvious example of "postdigital".</p> | |||
<p>But not all that is called "postdigital" is non-digital. Actually, much | |||
of it is very profoundly digital – pixel art and glitch art for example. The | |||
term is somewhat misleading – it does not only mean "the non-digital that | |||
comes after digital", but can also be read as "a later form of digital" or | |||
"something that comes after the digital revolution". It particularly seems | |||
to set itself apart from the "progress narrative" that wants to continuously | |||
replace everything with "bigger and better". This makes the idea relevant to | |||
permacomputing as well.</p> | |||
<p>When advocating lifestyles that abandon maximalism, it is important to | |||
frame it in a positive way. Settling for simple and coarse things does not | |||
need to be a "sacrifice" but something genuinely better than the mainstream | |||
alternative. "Postdigitality" is already a prominent force in e.g. indie | |||
games that often choose to use pixel graphics as a "modern" esthetic | |||
preference rather than as "retro nostalgia". This gives hope that a major | |||
paradigm shift is possible for the mainstream digital culture in | |||
general.</p> | |||
<p>During the global pandemic, many people have been extremely dependent on | |||
prohibitively complex digital blackboxes. I therefore assume that, once the | |||
pandemic is over, many people will want to distance themselves from the | |||
mainstream digital world. To concentate on non-digital things but also to | |||
find a healthier relationship with the digital. I think this is something | |||
that advocates of radically sustainable computing should tap into.</p> | |||
<h2>Links</h2> | |||
<p>(Added 2021-08-27) Here are some links I failed to include in the | |||
original version of this page:</p> | |||
<ul> | |||
<li><a href="https://moddingfridays.bleu255.com/Main_Page">Modding | |||
Fridays</a>: "An online community of people interested to learn together about the maintenance, repurposing, and reappropriation of supposedly obsolete consumer electronics, for fun and profit. We see our interest as part of a broader conversation on post-digital culture, permacomputing and repair | |||
culture". Includes a wiki and an XMPP chatroom.</li> | |||
<li><a href="http://civboot.org/">Civboot</a> is an educational project | |||
aiming at simplifying the requirements and dependencies of computer | |||
technology as well as increasing humanity's ability to understand it.</li> | |||
<li><a href="https://wiki.xxiivv.com/site/permacomputing.html">Permacomputing | |||
at the XXIIVV Wiki</a></li> | |||
<li><a href="https://communitywiki.org/wiki/SimpleSystemsManifesto">Simple | |||
Systems Manifesto</a></li> | |||
</ul> | |||
<p>Written by Ville-Matias "<a href="http://www.viznut.fi/">Viznut</a>" Heikkilä.<br> | |||
<b>2021-08-12</b>: initial release<br> | |||
<b>2021-08-27</b>: added the links section<br> | |||
<a rel="license" href="http://creativecommons.org/licenses/by/4.0/"> | |||
<img alt="Creative Commons License" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAFgAAAAfCAMAAABUFvrSAAAADFBMVEUAAAD///99fX2+w7rj0zguAAAA4klEQVRIx7WWgQ6FIAhFYf3/P9cjMX0K3rvStVwDT3QTRFS2jB/22DBkE9fI/WuwV639GnOrEILN/R6jKW4DCEaWftVWsWVJyjWX3M9NHTcne7j3fQH+42Zk8NNuy8BNlhTXOi3AqiM5V2KhhYGfv9xPH4DdV+oUrmGk8K1z3XzKwN2uQMBtJIDIwHZjwXCCUFIwKU39PKYIUduNKptMglCFnklp7gQhihB56M3L5tujOqqG75uA+dEU9wyWH6V5wMjR89CM2KVgzMf0IYpYRHE5ZskVRizKKA1g2Yi3tIU7sCfXlRBdibyVCwAAAABJRU5ErkJggg=="></a><br> | |||
This work is licensed under a | |||
<a rel="license" href="http://creativecommons.org/licenses/by/4.0/"> | |||
Creative Commons Attribution 4.0 International License</a>.</p> | |||
</article> | |||
<hr> | |||
<footer> | |||
<p> | |||
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use> | |||
</svg> Accueil</a> • | |||
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-rss2"></use> | |||
</svg> Suivre</a> • | |||
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-user-tie"></use> | |||
</svg> Pro</a> • | |||
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-mail"></use> | |||
</svg> Email</a> • | |||
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-hammer2"></use> | |||
</svg> Légal</abbr> | |||
</p> | |||
<template id="theme-selector"> | |||
<form> | |||
<fieldset> | |||
<legend><svg class="icon icon-brightness-contrast"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-brightness-contrast"></use> | |||
</svg> Thème</legend> | |||
<label> | |||
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
</label> | |||
<label> | |||
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
</label> | |||
<label> | |||
<input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
</label> | |||
</fieldset> | |||
</form> | |||
</template> | |||
</footer> | |||
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script> | |||
<script> | |||
function loadThemeForm(templateName) { | |||
const themeSelectorTemplate = document.querySelector(templateName) | |||
const form = themeSelectorTemplate.content.firstElementChild | |||
themeSelectorTemplate.replaceWith(form) | |||
form.addEventListener('change', (e) => { | |||
const chosenColorScheme = e.target.value | |||
localStorage.setItem('theme', chosenColorScheme) | |||
toggleTheme(chosenColorScheme) | |||
}) | |||
const selectedTheme = localStorage.getItem('theme') | |||
if (selectedTheme && selectedTheme !== 'undefined') { | |||
form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
} | |||
} | |||
const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
window.addEventListener('load', () => { | |||
let hasDarkRules = false | |||
for (const styleSheet of Array.from(document.styleSheets)) { | |||
let mediaRules = [] | |||
for (const cssRule of styleSheet.cssRules) { | |||
if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
continue | |||
} | |||
// WARNING: Safari does not have/supports `conditionText`. | |||
if (cssRule.conditionText) { | |||
if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
continue | |||
} | |||
} else { | |||
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
continue | |||
} | |||
} | |||
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
} | |||
// WARNING: do not try to insert a Rule to a styleSheet you are | |||
// currently iterating on, otherwise the browser will be stuck | |||
// in a infinite loop… | |||
for (const mediaRule of mediaRules) { | |||
styleSheet.insertRule(mediaRule.cssText) | |||
hasDarkRules = true | |||
} | |||
} | |||
if (hasDarkRules) { | |||
loadThemeForm('#theme-selector') | |||
} | |||
}) | |||
</script> | |||
</body> | |||
</html> |
@@ -0,0 +1,632 @@ | |||
title: Permacomputing Update 2021 | |||
url: http://viznut.fi/texts-en/permacomputing_update_2021.html | |||
hash_url: 0f791a9509f762f1a1a36b6ca2333230 | |||
<p>It is now more than a year since I wrote <a href="http://viznut.fi/texts-en/permacomputing.html">my "early notes" about | |||
Permacomputing</a>. At that time, I was not yet aware of anyone else having | |||
similar ideas, so I've now decided to write an update that connects my ideas | |||
with the existing discussions and activities. I also want to share some new | |||
ideas I have been pondering about. This text is about 33K characters / 4900 | |||
words long, so allocate your time accordingly.</p> | |||
<h2>1. A fragmented pluriverse</h2> | |||
<p>The "biosphere-aware computing scene" is quite fragmented. There are many | |||
different islands (groups and individuals) that use different terminology | |||
and that are only now discovering each other. It is therefore important to | |||
build bridges between the islands.</p> | |||
<p><a href="https://computingwithinlimits.org/">Computing within Limits | |||
workshops</a> that started in 2015 form an important hub but have been | |||
rather invisible from non-academic perspectives. Many interesting papers | |||
have come out of these workshops, but I would really like to see more | |||
practical and/or longer-term projects that go beyond the shortish workshop | |||
papers. Computing within Limits branched out of a larger field of | |||
"sustainable" ITC <a href="http://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-375131">that is known | |||
to have huge problems</a>.</p> | |||
<p>Another hub is in the <a href="https://en.wikipedia.org/wiki/Fediverse">Fediverse</a>, particularly | |||
around the Mastodon server <a href="https://merveilles.town/">Merveilles.town</a> that centers around | |||
creativity and sustainable technology. Many of these productive hackers, | |||
artists and activists also participate in the "smolnet"/"smallnet", | |||
including the space of the <a href="https://gemini.circumlunar.space/">Gemini</a> protocol. My | |||
Permacomputing article was very well received in these circles and many have | |||
adopted the concept for their use.</p> | |||
<p>Then there's the "Sustainable Internet" activism that has the <a href="https://branch.climateaction.tech/about">Branch online magazine</a>. I | |||
tend to lump this together with the various "solar web" projects such as the | |||
<a href="https://www.lowtechmagazine.com/2020/01/how-sustainable-is-a-solar-powered-website.html">solar-powered | |||
version of Low-Tech Magazine</a> and the <a href="http://solarprotocol.net/">Solar Protocol</a>. Also somewhat related | |||
is the <a href="https://smallfile.ca/">Small File Media Festival</a> that | |||
criticizes the carbon footprint of streamed media with smallish (video) | |||
files. This is an area where the demoscene could make important | |||
contributions.</p> | |||
<p>In addition to the generic groups of like-minded people, there are | |||
specific projects, such as <a href="https://collapseos.org/">Collapse | |||
OS</a>, whose participants don't necessarily have connections to wider | |||
groups.</p> | |||
<p>Occasionally, an online article pops up that expresses similar concerns | |||
and ideas as I did with the Permacomputing essay, like Wim Vanderbauwhede's | |||
<a href="https://wimvanderbauwhede.github.io/articles/frugal-computing/">Frugal | |||
computing</a>. It is great to see that many different people independently | |||
come to similar conclusions, but this can also be seen as a sign that we | |||
need more social media activism and awareness-rising even to make all the | |||
concerned people find each other.</p> | |||
<p>Marloes de Valk has been <a href="https://computingwithinlimits.org/2021/papers/limits21-devalk.pdf">mapping</a> | |||
this scattered "pluriverse" and its terminology, but I have the feeling that | |||
this only scratches the surface, and that there's a lot of relevant practice | |||
going on in e.g. non-Western countries.</p> | |||
<p>A major problem with this "pluriverse" is the lack of a common name to be | |||
used in communication. "Permacomputing" scored quite high in De Valk's | |||
Fediverse poll, and I have no objections against using it for this purpose. | |||
Something like "radically sustainable computing" might also be a good | |||
umbrella term ("radically" being the keyword that differentiates it from the | |||
greenwashed capitalism of "Sustainable ITC").</p> | |||
<h2>2. Collapse Informatics</h2> | |||
<p>Many of the early Computing within Limits papers discuss collapse and | |||
scarcity scenarios from somewhat bleak viewpoints. In later years, the | |||
research community started to reframe itself in more positive ways by | |||
drawing inspiration from e.g. Hes & du Plessis' <i><a href="https://www.routledge.com/Designing-for-Hope-Pathways-to-Regenerative-Sustainability/Hes-Plessis/p/book/9781138800625">Regenerative | |||
Sustainability</a></i> and Escobar's <i><a href="https://www.dukeupress.edu/designs-for-the-pluriverse/">Designs for | |||
the Pluriverse</a></i> – just like Permacomputing draws inspiration from | |||
Permaculture. But even when focusing on a positive vision, one should not | |||
take anything for granted. If a vision cannot survive a collapse of | |||
industrial production or network infrastructure, it isn't resilient | |||
enough.</p> | |||
<p>An important paper in the collapse vein is Jang et al.'s <i><a href="https://kurti.sh/pubs/unplanned_limits17.pdf">Unplanned Obsolescence: | |||
Hardware and Software After Collapse</a></i> that e.g. estimates lifetimes for | |||
various hardware components, with the conclusion that it may be possible to | |||
maintain some of current computer hardware for several human generations | |||
even if the entire semiconductor industry collapsed right now. Solderpunk | |||
(the creator of the afore-mentioned Gemini) has a concrete proposal for a | |||
"<a href="gopher://zaibatsu.circumlunar.space/0/%7esolderpunk/phlog/the-standard-salvaged-computing-platform.txt">standard | |||
salvaged computing platform</a>" based on smartphone/tablet e-waste. I'm | |||
sure that there are components with much longer potential lifespans (Jang et | |||
al. estimate current mobile hardware to be able to persist for about one | |||
generation), but at least there would be heaps of this type of junk | |||
available in the early years. I'm personally interested by the possibilities | |||
of microcontroller-based smartcards (that are even more ubiquitous than | |||
mobile phones but have entirely different challenges).</p> | |||
<p>Jang et al. also have a few interesting words about maintenance culture. | |||
In the same way as religious organizations continued to maintain ancient | |||
Chinese roads that no longer received governmental support, computing could | |||
be maintained in a post-collapse world by "semi-ascetic cultural | |||
organizations whose primary focus may or may not be computing". I have | |||
personally been fascinated by the potential of monastery-like communities to | |||
preserve science and technology even during "dark ages" when the society at | |||
large sees no value in them. In medieval Europe, some monasteries even | |||
refined and advocated technologies such as <a href="https://www.researchgate.net/publication/271064820_Wind_and_Water_in_the_Middle_Ages_Fluid_Technologies_from_Antiquity_to_the_Renaissance">water | |||
power</a>.</p> | |||
<p>The term <i><a href="https://www.researchgate.net/publication/262276832_Collapse_Informatics_and_Practice_Theory_Method_and_Design">collapse | |||
informatics</a></i> comes from Bill Tomlinson who suggests that one should look | |||
into the existing computing practices in groups that have voluntarily chosen | |||
to live off-grid or in other "collapse-like" conditions. I might also want | |||
to include those who do so involuntarily, as well as those who have made | |||
"collapse-compatible" decisions specifically with computing (e.g. artists | |||
who specialize in old hardware).</p> | |||
<p>I don't know if there is going to be a collapse, but I'm quite sure that | |||
the entire society needs to reduce energy consumption, lengthen | |||
technological lifespans and reduce superfluous dependencies. Recognizing the | |||
possiblity of a collapse may help coordinate these changes. <i><a href="https://www.ceguide.org/Strategies-and-examples/Design/Design-for-disassembly-deconstruction">Designing for | |||
disassembly</a></i> is an example of a concrete goal that supports hardware | |||
longevity in both collapse and non-collapse scenarios.</p> | |||
<h2>3. Anti-utilitarianism</h2> | |||
<p>In profit-oriented societies, people often try to make themselves and | |||
their fields of expertise as important and useful as possible. It has | |||
therefore been delightful to learn about visions that detach computing from | |||
all utilitarian purposes.</p> | |||
<p>Brendan Howell's <i><a href="https://moddr.net/rustic-computing/">Rustic | |||
Computing</a></i> is an artistic project that depicts computing as "the pastime | |||
of dilettantes, amateur scientists and gentleman tabulators who construct | |||
machines to manipulate abstract symbols with no practical application". | |||
Computer components are built using pre-industrial technology, which reminds | |||
me of early mechanical computers such as Zuse's Z1. When computers are built | |||
with non-pollutive technologies, they don't need to justify their existence | |||
by paying back their ecological debts. And since they have no practical | |||
purpose, they don't even have to be faster or better than manual | |||
paper-and-pencil calculation. They can just be interesting and important the | |||
way they are.</p> | |||
<p>I see much of the same attitude in <i><a href="https://compudanzas.net/about.html">Compudanzas</a></i>, a research | |||
project that reimagines computing in the form of "seemingly useless" | |||
activities such as rituals and dancing.</p> | |||
<p>In Steve Lord's idea of <i><a href="https://thedorkweb.substack.com/p/the-100-year-computer">Heirloom | |||
Computing</a></i>, a computer that has been made to last for many generations | |||
can be a piece of family history that evolves with the family, keeping | |||
permanent traces from every generation that has used it, and does not need | |||
to have any purpose besides this.</p> | |||
<p>As suggested by Jang et al., a post-collapse society that has eventually | |||
lost all of its artificial computing capacity may still want to continue the | |||
practice of computer science in a purely theoretical level, as a form of | |||
mathematics. This is another example of how computing may remain meaningful | |||
for some pockets of culture even with no ability to run any potential | |||
applications.</p> | |||
<p>Detachment from utilitarism may (perhaps paradoxically) give way to a | |||
deeper importance and meaning. I'm particularly thinking about Yuk Hui's | |||
idea of <i><a href="https://www.academia.edu/35561477/On_Cosmotechnics_For_a_Renewed_Relation_between_Technology_and_Nature_in_the_Anthropocene">Cosmotechnics</a></i> | |||
which refers to a unified harmony between technology, culture and non-human | |||
nature. Modern technological thinking lost this harmony by turning | |||
everything into utilitarian resources. An interesting point made by Hui is | |||
that every culture should find its own approach to cosmotechnics – so, we | |||
would be replacing a homogenous global utilitarian monoculture with a rich | |||
and diverse polyculture.</p> | |||
<h2>4. Limits of imagination</h2> | |||
<p>It is often difficult to even imagine a kind of computer culture that | |||
does not suffer from unlimited growth. Even the most interesting real-world | |||
examples (such as the Soviet computing culture) exist somewhat in the shadow | |||
of Western developments and ideologies. So, there's no real "other" to | |||
contrast the growth-obsessed mainstream computing with.</p> | |||
<p>Computing within Limits papers have also given me an impression that some | |||
scholars even find it difficult to imagine e.g. how software development | |||
could take place without the Internet. In cases like this, I might suggest | |||
looking into the actual history and listening to people who have experienced | |||
it. Even though the history of computing isn't nearly as diverse as it could | |||
or should be, it is still worthwhile to study it. And definitely not only | |||
the mainstream "winners' history" but everything from the various cultures | |||
and subcultures.</p> | |||
<p>Eriksson and Pargman <a href="https://computingwithinlimits.org/2018/papers/limits18-eriksson.pdf">have | |||
suggested the use of counterfactual history</a> to assist imagination. | |||
Sadly, their own <i><a href="https://www.researchgate.net/project/Coalworld">Coalworld</a></i> | |||
scenario (with the point of divergence being an early-seventies "peak oil" | |||
event) has not yet reached the point where computing can be elaborated. I | |||
wish there was more speculation (both fiction-oriented and academically | |||
rigorous works) that would present thoroughly-imagined alternatives to the | |||
actual history.</p> | |||
<h2>5. Alternative paradigms</h2> | |||
<p>I've already mentioned several "alternative paradigms of computing": | |||
<i>frugal computing</i>, <i>heirloom computing</i>, <i>rustic computing</i>, | |||
<i>collapse informatics</i>. But there are still a few more to add:</p> | |||
<p><i><a href="https://computingwithinlimits.org/2018/papers/limits18-mann.pdf">Regenerative | |||
computing</a></i> is Mann et al.'s idea of applying Hes & du Plessis' | |||
<i>Regenerative sustainability</i> to computing. The most | |||
Permacomputing-relevant part of the Limits'18 is quite dense, so I'll quote | |||
it verbatim: (number 7 refers to Hes & du Plessis' 2014 book <i><a href="https://www.routledge.com/Designing-for-Hope-Pathways-to-Regenerative-Sustainability/Hes-Plessis/p/book/9781138800625">Designing | |||
for hope: pathways to regenerative sustainability</a></i>)</p> | |||
<blockquote> | |||
(3) Move beyond efficiency as the primary lever available to computing. - | |||
These new narratives should look to nature and ecology to demonstrate the | |||
interplay between computing, society and biological systems where limits of | |||
these systems are respected and worked with.<br> | |||
(4) Integrate ecological worldviews into computing's narratives and | |||
processes both the theory such as living systems and deep ecology, and | |||
values sets: | |||
<ul> | |||
<li>Integrity - maintaining the wholeness of [wider] systems, ensuring that | |||
structure and relationships remain intact and functioning as they | |||
should.</li> | |||
<li>Inclusivity - "interacting with the world in its entirety" [7, p. 35], | |||
engaging and integrating with all dimensions, levels of existence and | |||
knowledge.</li> | |||
<li>Harmony - all elements cooperate through relationships that are | |||
respectful in order to avoid dissonance.</li> | |||
<li>Respect - all parts of the world have intrinsic worth and all existence | |||
is part of the extended self, and therefore all self-respect is extended to | |||
mutual respect for the world.</li> | |||
<li>Mutuality - "we are in this together, and what happens to ‘others’ will | |||
also have an effect on self" - see: compassion, treating others the same as | |||
yourself.</li> | |||
<li>Positive reciprocity - "reciprocating in a way that is | |||
of benefit to and advances the relationship between | |||
self and extended self" [7, p. 35].</li> | |||
<li>Fellowship - an extension of mutuality and positive reciprocity, where | |||
the world is co-created by humans in partnership with nature.</li> | |||
<li>Responsibility - morally accountability for the consequences of our | |||
actions in an uncertain and unpredictable world</li> | |||
<li>Humility - change is constant, we cannot know the true consequences of | |||
our actions</li> | |||
<li>Non-attachment - In order to adapt to changing circumstances it is | |||
important to uphold non-attachment in order to decouple from “the futility | |||
of trying to hold onto anything in an ever changing world including ideas, | |||
dogmas and strategies” [7, p. 36]</li> | |||
</ul> | |||
</blockquote> | |||
<p><i>Convivial computing</i>, from <a href="https://www.researchgate.net/publication/235173004_Constrained_Design_Processes_Steps_Towards_Convivial_Computing">Fischer | |||
& Lemke's 1987 paper</a>, is an earlier example of taking ideas from | |||
ecologically conscious thinking into computing (in this case, from Ivan | |||
Illich's book <i>Tools for Conviviality</i>). Even earlier, Lee Felsenstein | |||
had been inspired by the same book when designing the Osborne 1 personal | |||
computer. In both cases, however, the ecological aspects of Illich's thought | |||
are ignored. Also, Fischer & Lemke's paper doesn't feel at all like a | |||
forgotten masterpiece of groundbreaking thought – the ideas actually seem to | |||
be very much in line with what was implemented in the "<a href="https://en.wikipedia.org/wiki/Rapid_application_development">RAD</a> | |||
tools" of the 1990s. And some of these tools (Delphi, Visual Basic) felt | |||
like the epitome of bloat at the time.</p> | |||
<p><i><a href="https://computingwithinlimits.org/2015/papers/limits2015-raghavan.pdf">Benign | |||
computing</a></i> basically advocates keeping things small in order to keep | |||
the problems caused by them small. Currently, huge problems are created by | |||
huge, centrally-managed systems built with the principles of abstraction and | |||
indirection. Raghavan's critique of these principles is very similar to how | |||
I see "<a href="http://viznut.fi/texts-en/maximalism_virtualism.html">maximalism and | |||
virtualism</a>". I also completely agree with Raghavan about that "the | |||
utopian notion of creating new technology that is strictly "beneficial" or | |||
that advances "development"" must be rejected.</p> | |||
<h2>6. Permacomputing practice</h2> | |||
<p>My Permacomputing article from 2020 is basically a vision of a new kind | |||
of computing that works in a radically different way in a radically | |||
different society. It does not give many guidelines towards actual practice | |||
or how to transition towards permacomputing, so maybe I should cover this | |||
area a little bit.</p> | |||
<p>I have been reluctant to name specific technologies or design constraints | |||
for permacomputing. This is because I want to support a diverse polyculture | |||
of ideas and possibilities. Asking what is the most suitable programming | |||
language for permacomputing is a bit like asking what is the most suitable | |||
plant for permaculture – the entire question contradicts itself. There is no | |||
"silver bullet" – there isn't one even in the mainstream industry despite | |||
its continuous attempts to uniformize everything. However, there can be | |||
design wisdom about the strengths, weaknesses and mutual interactions of | |||
specific elements, and this wisdom helps with choosing a language, a plant, | |||
an algorithm or a design pattern for a specific place.</p> | |||
<p>In software, nothing that can be run locally is "poisonous" per se. Even | |||
if something consumes a lot of energy, it does not need to mean more than | |||
that the consumption must be restricted to when that energy is available. | |||
Far more important questions are how the hardware is obtained and | |||
maintained, and how the energy is produced.</p> | |||
<p>I have noticed that many "sustainable" or even "low-tech" computing | |||
projects have been built on cheap DIY-oriented boards such as Raspberry Pi. | |||
Even though these may be among the best of the currently available options, | |||
it should be noted that they have been designed for hackability and | |||
replaceability rather than longevity or repairability. There might be a need | |||
for a radically repairable and modifiable hardware basis to fulfill similar | |||
purposes. Radical modifiability might include the ability to interface with | |||
a large variety of different chips (processors, SoCs etc.) – this would help | |||
maximize the usable lifespans of those chips.</p> | |||
<h3>6.1. Low complexity</h3> | |||
<p>Keeping systems very simple but very capable is a good guideline for a | |||
lot of permacomputing, but particularly so for the crucial basic software | |||
used to enable salvaged/makeshift hardware. Bare-hardware Forth systems | |||
(such as Collapse OS or OpenBIOS) are very capable for their low complexity, | |||
and can be small enough even for rudimentary 8-bit microcontrollers.</p> | |||
<p>One possible approach to simplicity is to try to keep things simple | |||
enough that they can be thoroughly understood and (re)implemented by one | |||
person. This applies not only to application programs but the dependent | |||
elements as well (programming language, operating system, firmware, | |||
hardware). This is not to say that people should write everything from | |||
scratch but to keep the complexity human-graspable. The ideal of human-sized | |||
computing is particularly applicable to systems that are used as tools | |||
(because tools in general should be thoroughly understandable to their | |||
users). Also, in decentralized "post-collapse" societies, the local | |||
all-around experts ("village hackers") should be able to master all aspects | |||
of the local computing systems in order to maintain them and to adapt them | |||
to various local needs. All this becomes much easier if complexities are | |||
kept low or moderate.</p> | |||
<p>The effective complexity of a software program can be estimated by | |||
summing its executable size with the size of the minimum set of dependencies | |||
required to run it (including the OS components). Alternatively, one can | |||
calculate its bootstrap complexity (by summing the size of all code and data | |||
required to compile the program, the dependencies, and the entire dependency | |||
network of the toolset required for the compilation in the smallest system | |||
that can run them). These types of assessment strongly favor programs that | |||
are written in non-bloated languages and can be made run on bare hardware – | |||
even if they can also run in bloated environments and use their special | |||
features.</p> | |||
<p>One way to deal with huge platforms is to create "pockets of simplicity" | |||
such as <a href="https://100r.co/site/uxn.html">simple virtual machines</a> | |||
that can also run on bare hardware. Emulators of existing hardware platforms | |||
are a special case of this. VMs are particularly suitable for small things | |||
that require far less computation than what the hardware is capable of. A | |||
virtual machine may also help eliminate compatibility problems and code rot, | |||
if it is unambiguously defined and the definition is canonized (permanently | |||
frozen). If approached with mainstream engineering attitudes, however, VMs | |||
may easily lead to "Java-like" problems (wastefulness, incompatibilities, | |||
etc.) Setting artificial limits to memory usage and execution speeds may | |||
prevent some of these developments. One might also want to think about how | |||
to statically translate VM programs into native code for running on | |||
platforms that are actually small.</p> | |||
<p>In mainstream computing, "ease of use" is usually implemented as | |||
"superficial simplicity" or "pseudo-simplicity", i.e. as an additional layer | |||
of complexity that hides the underlying layers. Meanwhile, systems that are | |||
actually very simple and elegant are often presented in ways that make them | |||
look complex to laypeople (think about the esoteric syntax of Forth or Lisp, | |||
for example). Ideally, UIs should reflect, amplify and illustrate the | |||
underlying elegance instead of trying to hide or misrepresent the inner | |||
workings. The earliest versions of the Apple Macintosh OS manage to do this | |||
to some extent (the system is not much more complex than the UI | |||
representation, every file is represented by an icon, program files are | |||
stand-alone without external dependencies, etc.)</p> | |||
<p>When minimizing the internal complexity of a system, however, it should | |||
not be isolated from the complexity of the external world. Computers are | |||
dependent on energy availability, temperature and other conditions, so they | |||
should be able to adjust their operation to the changes in these conditions | |||
– even if environmental monitoring is not among their designated tasks.</p> | |||
<h3>6.2. Towards concrete examples</h3> | |||
<p>Permacomputing has so far been defined in ways that emphasize generic | |||
ideas and a wide diversity of possibilities. However, in order to actually | |||
create something that represents permacomputing, one needs to make a lot of | |||
specific design decisions. Concrete examples (either real projects or | |||
mockups) may help with this. In order to cover the possibility space, we | |||
need a lot of different examples from different points of view.</p> | |||
<p>One possible starting point is to think about a general-purpose | |||
single-user computer that remains usable and relevant as long as possible | |||
even in a collapse scenario. Of course, any computer should be | |||
end-user-programmable and have some kind of programming interface to | |||
facilitate it, but what would be the concrete applications this kind of | |||
computer would be used for?</p> | |||
<p>I assume that viewing text files from physical storage devices (such as | |||
flash memory) is what would persist the longest in any scenario. A few | |||
gigabytes of storage would be enough for an entire library of literature | |||
that could be valuable for centuries. And accessing it would be possible | |||
(although not comfortable) even with very rudimentary post-collapse I/O | |||
devices (such as a few switches and indicators for a manual serial protocol | |||
– somewhat like using a Morse code telegraph).</p> | |||
<p>It may be theoretically possible to even read data directly from a USB | |||
flash drive with this kind of manual "telegraphy", but the complexity of the | |||
USB protocol would probably get overwhelming. Fortunately, a complex | |||
protocol implies that there is a (re)programmable microcontroller in the | |||
device, so one may want to reprogram it to support a simpler protocol. One | |||
could also add a "backdoor" that enables the device to run arbitrary | |||
programs from the drive, thus unleashing its potential for general-purpose | |||
computing. It may even be possible to get a USB stick to drive "proper" | |||
interface devices such as display screens despite the low number of I/O pins | |||
(two output pins are enough for composite video, but LCD panels | |||
unfortunately tend to need much more, so some kind of a multiplexer would be | |||
required). This could help reduce and postpone the need for "Morse | |||
code".</p> | |||
<p>These could become general guidelines for maximizing the lifespans of | |||
arbitrary programmable devices: 1) make it as straightforward as possible to | |||
run arbitrary code, 2) support an electrically simple interface that can | |||
even be operated manually in times of far-future scarcity.</p> | |||
<p>Another persistent application besides file viewing would be text | |||
editing. It has been prominent in personal computers since the early years | |||
and probably will be in just about any scenario. It would also imply the | |||
need for general file management tasks such as copying files between storage | |||
devices. Programs for doing these tasks would be among the first to | |||
implement for any "permacomputer" that does not require special expertise to | |||
use.</p> | |||
<p>Telecommunication is important but does not require computers – messages | |||
may well be relayed with classical amateur radio methods. Also, computer | |||
file-sharing networks can well be based on physical media. However, the | |||
existence of a radio and a computer makes it appealing to combine the two. A | |||
program for transferring files and text streams over abritrary channels, in | |||
one- or two-way protocols or packet protocols, with or without error | |||
correction and/or encryption, would be a fine inclusion to the set of | |||
"collapse software".</p> | |||
<p>Of course, supporting far-future post-collapse scenarios does not mean | |||
that one should stick to far-future post-collapse practices – rather, it | |||
ensures that there are fallbacks for everything. You can use a | |||
high-resolution screen today, but the system will work fine even with | |||
tomorrow's more rudimentary display. You can run a complex OS today, but the | |||
simple OS in the firmware ROM is also perfectly fine for editing a text | |||
document.</p> | |||
<p>I imagine that this "simple OS" would normally look either like a plain | |||
Forth interpreter or an orthodox file manager (i.e. a Norton Commander | |||
clone), depending on whether the computer is connected to a sufficient | |||
screen or not. For screens that are a bit too small for the OFM there might | |||
also be an intermediate option that resembles early-2000s cellphone | |||
interfaces. All of these modes would be usable even with quirky input | |||
devices (such as a game controller, a single telegraph key or a barely | |||
functional touchscreen). Hardware is accessed via Forth words that can be | |||
straightforwardly redefined if there are unexpected hardware changes (such | |||
as specific glitches that need to be bypassed).</p> | |||
<p>The OFM would allow one to browse, view and manipulate files, run | |||
executable files, edit text files and enter Forth commands. It could also be | |||
set up as a bootloader to load a more complex OS, but loading one would | |||
often be unnecessary, as many programs (especially ones that favor | |||
single-tasking) would also be available as "Forth" executables (that may | |||
also be native binaries that may or may not use Forth words) or as "ROM" | |||
files runnable with a simple VM.</p> | |||
<p>Systems that don't have much capacity to spare would perhaps only have a | |||
plain Forth interpreter, or if even that would be too bloated, something | |||
like the standard byte protocol used by smartcards.</p> | |||
<p>Longevity maximization easily leads to an emphasis on conservative and | |||
well-tested ideas, so this example may sound a little bit bleak. A fancier | |||
starting point (such as one based on ideas from unconventional computing) | |||
would perhaps give more room for fancier permacomputing ideas that take more | |||
distance from fossil-era computing.</p> | |||
<h3>6.3. Sustainable cyberspace</h3> | |||
<p>There are many projects that address the sustainability problems of the | |||
World Wide Web. Activism for sustainable websites, solar-powered servers, | |||
new protocols, simpler document formats. However, these often take the | |||
underlying Internet for granted. The access may perhaps be slow at times or | |||
places, and a solar-powered server may be sometimes offline, but any place | |||
of the world is still supposedly accessible from any other place of the | |||
world at any time. The weirdness of this assumption may not even be obvious | |||
to modern Internet users – after all, it is in the core of nearly every | |||
major service/protocol (perhaps apart from Email and Usenet that can also | |||
propagate over temporary connections).</p> | |||
<p>I see need for a decentralized protocol that works painlessly in | |||
conditions where everything is not constantly available. Where individual | |||
servers or communication links may be online or offline depending on | |||
circumstances. Where other parts of the network may only be accessible via | |||
temporary connections, physical file-sharing or data mules. Where your | |||
messages still reach their destinations, where you still get the files you | |||
need, and where "social media" discussions can still thrive, despite all | |||
these logistical constraints.</p> | |||
<p>For some inspiration for the required mindset, one may think about how | |||
files were collected and propagated in "pre-Internet" conditions (BBSes, | |||
friend-to-friend file copying) and how to make these processes as automatic | |||
as possible.</p> | |||
<h2>7. Collapse-tolerant business</h2> | |||
<p>I don't often think about how to do business in the capitalist economy, | |||
but in the early 2021 I asked myself what kind of IT company (or other type | |||
of IT-related organization) would thrive both before and after a collapse. I | |||
wanted to challenge my prejudice that anything you do for profit/living will | |||
always be somewhat "greenwashed" instead of properly sustainable.</p> | |||
<p>Here are my ideas of how a relatively small "permacomputing company" | |||
could operate in the "age of abundance":</p> | |||
<ul> | |||
<li>Accept software-related and other customer projects just like any | |||
average IT company, as long as they are in line with strict eco-ethical | |||
standards. Refuse to contribute to the wasteful use of resources, and | |||
strongly prefer doing things in sustainable and robust ways. Make these | |||
standards a part of the company brand.</li> | |||
<li>Have long-term in-house research and development projects related to | |||
radically sustainable computing, both software and hardware. Convince | |||
investors about their vitality to the future of civilization. Also practice | |||
permaculture (or constantly co-operate with ones who do) and try to connect | |||
it to everything else that the company is doing.</li> | |||
<li>Self-host everything you need for software work on local physical | |||
servers. This includes all networked applications as well as an extensive | |||
library of software and documentation (including repair manuals and OS | |||
distributions for all relevant hardware). Offer hosting services to make | |||
use of the surplus.</li> | |||
<li>Produce as much of your own energy as possible with solar panels, wind | |||
turbines etc. Sell the surplus to the company that maintains the grid.</li> | |||
<li>Repair and maintain all hardware by yourself. Maintain a storage | |||
facility for old/recycled hardware. Offer services related to repairing and | |||
recycling (in a small scale, for now). Maintain a hackerspace or constantly | |||
co-operate with one.</li> | |||
<li>Support forms of culture that strengthen the status of radically | |||
sustainable computing/technology (e.g. hackerspaces, education, demoscene | |||
events, art projects that use "obsolete" hardware, etc.)</li> | |||
<li>Make sure that many of the employees live close to the office. Maintain | |||
spaces that can be turned into apartments once transportation becomes more | |||
difficult.</li> | |||
</ul> | |||
<p>Once the world has completely changed, the focus or the organization will | |||
become somewhat wider: | |||
</p><ul> | |||
<li>Accept any customer projects related to computing or any other | |||
technology you happen to understand. Offer repair services.</li> | |||
<li>Collect/buy "e-waste", build working computers and appliances out of it, | |||
sell them.</li> | |||
<li>Keep in contact with the rest of the "computing scene" even if | |||
long-range communication networks have collapsed. Share information and | |||
trade hardware components. Use couriers if necessary.</li> | |||
<li>If microchips or some other essential components are no longer produced, | |||
participate in attempts to restart the production (in a small scale, for | |||
now – until we learn how to do it sustainably).</li> | |||
<li>Similarly, try to rebuild communication networks if they have collapsed. | |||
Offer communications services, maybe maintain "Internet cafés".</li> | |||
<li>Maintain digital and physical libraries of pre-collapse and | |||
post-collapse information. Print physical books. Participate in projects | |||
that support the continuing existence of science and education.</li> | |||
<li>Make sure that technological understanding will pass on to new | |||
generations. If necessary, educate the new employees (or cult members or | |||
whatever they may be called) from scratch.</li> | |||
<li>If it becomes impossible to make living out of this, start depending on | |||
agriculture. But in any case don't forget the importance of science and | |||
technology. If necessary, explain the importance in religious terms.</li> | |||
</ul> | |||
<h2>8. Postdigital advocacy</h2> | |||
<p>Art researchers recognize the concept of "postdigital" as a reaction | |||
against the so-called "digital revolution" that took place in the nineties, | |||
and especially against the typically "digital" esthetics. Using cassette | |||
tapes for music in a world where digital music formats are ubiquitous is an | |||
obvious example of "postdigital".</p> | |||
<p>But not all that is called "postdigital" is non-digital. Actually, much | |||
of it is very profoundly digital – pixel art and glitch art for example. The | |||
term is somewhat misleading – it does not only mean "the non-digital that | |||
comes after digital", but can also be read as "a later form of digital" or | |||
"something that comes after the digital revolution". It particularly seems | |||
to set itself apart from the "progress narrative" that wants to continuously | |||
replace everything with "bigger and better". This makes the idea relevant to | |||
permacomputing as well.</p> | |||
<p>When advocating lifestyles that abandon maximalism, it is important to | |||
frame it in a positive way. Settling for simple and coarse things does not | |||
need to be a "sacrifice" but something genuinely better than the mainstream | |||
alternative. "Postdigitality" is already a prominent force in e.g. indie | |||
games that often choose to use pixel graphics as a "modern" esthetic | |||
preference rather than as "retro nostalgia". This gives hope that a major | |||
paradigm shift is possible for the mainstream digital culture in | |||
general.</p> | |||
<p>During the global pandemic, many people have been extremely dependent on | |||
prohibitively complex digital blackboxes. I therefore assume that, once the | |||
pandemic is over, many people will want to distance themselves from the | |||
mainstream digital world. To concentate on non-digital things but also to | |||
find a healthier relationship with the digital. I think this is something | |||
that advocates of radically sustainable computing should tap into.</p> | |||
<h2>Links</h2> | |||
<p>(Added 2021-08-27) Here are some links I failed to include in the | |||
original version of this page:</p> | |||
<ul> | |||
<li><a href="https://moddingfridays.bleu255.com/Main_Page">Modding | |||
Fridays</a>: "An online community of people interested to learn together about the maintenance, repurposing, and reappropriation of supposedly obsolete consumer electronics, for fun and profit. We see our interest as part of a broader conversation on post-digital culture, permacomputing and repair | |||
culture". Includes a wiki and an XMPP chatroom.</li> | |||
<li><a href="http://civboot.org/">Civboot</a> is an educational project | |||
aiming at simplifying the requirements and dependencies of computer | |||
technology as well as increasing humanity's ability to understand it.</li> | |||
<li><a href="https://wiki.xxiivv.com/site/permacomputing.html">Permacomputing | |||
at the XXIIVV Wiki</a></li> | |||
<li><a href="https://communitywiki.org/wiki/SimpleSystemsManifesto">Simple | |||
Systems Manifesto</a></li> | |||
</ul> | |||
Written by Ville-Matias "<a href="http://www.viznut.fi/">Viznut</a>" Heikkilä.<br> | |||
<b>2021-08-12</b>: initial release<br> | |||
<b>2021-08-27</b>: added the links section<br> | |||
<a rel="license" href="http://creativecommons.org/licenses/by/4.0/"> | |||
<img alt="Creative Commons License" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAFgAAAAfCAMAAABUFvrSAAAADFBMVEUAAAD///99fX2+w7rj0zguAAAA4klEQVRIx7WWgQ6FIAhFYf3/P9cjMX0K3rvStVwDT3QTRFS2jB/22DBkE9fI/WuwV639GnOrEILN/R6jKW4DCEaWftVWsWVJyjWX3M9NHTcne7j3fQH+42Zk8NNuy8BNlhTXOi3AqiM5V2KhhYGfv9xPH4DdV+oUrmGk8K1z3XzKwN2uQMBtJIDIwHZjwXCCUFIwKU39PKYIUduNKptMglCFnklp7gQhihB56M3L5tujOqqG75uA+dEU9wyWH6V5wMjR89CM2KVgzMf0IYpYRHE5ZskVRizKKA1g2Yi3tIU7sCfXlRBdibyVCwAAAABJRU5ErkJggg=="></a><br> | |||
This work is licensed under a | |||
<a rel="license" href="http://creativecommons.org/licenses/by/4.0/"> | |||
Creative Commons Attribution 4.0 International License</a>. |
@@ -0,0 +1,209 @@ | |||
<!doctype html><!-- This is a valid HTML5 document. --> | |||
<!-- Screen readers, SEO, extensions and so on. --> | |||
<html lang="fr"> | |||
<!-- Has to be within the first 1024 bytes, hence before the `title` element | |||
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
<meta charset="utf-8"> | |||
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
<!-- The viewport meta is quite crowded and we are responsible for that. | |||
See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
<meta name="viewport" content="width=device-width,initial-scale=1"> | |||
<!-- Required to make a valid HTML5 document. --> | |||
<title>The Three Kinds of Organizational Power (archive) — David Larlet</title> | |||
<meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
<!-- That good ol' feed, subscribe :). --> | |||
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
<!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
<link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
<meta name="msapplication-TileColor" content="#f7f7f7"> | |||
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)"> | |||
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)"> | |||
<!-- Documented, feel free to shoot an email. --> | |||
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css"> | |||
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
<script> | |||
function toggleTheme(themeName) { | |||
document.documentElement.classList.toggle( | |||
'forced-dark', | |||
themeName === 'dark' | |||
) | |||
document.documentElement.classList.toggle( | |||
'forced-light', | |||
themeName === 'light' | |||
) | |||
} | |||
const selectedTheme = localStorage.getItem('theme') | |||
if (selectedTheme !== 'undefined') { | |||
toggleTheme(selectedTheme) | |||
} | |||
</script> | |||
<meta name="robots" content="noindex, nofollow"> | |||
<meta content="origin-when-cross-origin" name="referrer"> | |||
<!-- Canonical URL for SEO purposes --> | |||
<link rel="canonical" href="https://jacobian.org/2021/mar/15/organizational-power/"> | |||
<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all"> | |||
<article> | |||
<header> | |||
<h1>The Three Kinds of Organizational Power</h1> | |||
</header> | |||
<nav> | |||
<p class="center"> | |||
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use> | |||
</svg> Accueil</a> • | |||
<a href="https://jacobian.org/2021/mar/15/organizational-power/" title="Lien vers le contenu original">Source originale</a> | |||
</p> | |||
</nav> | |||
<hr> | |||
<p>Within an organization, there are three kinds of power structures: <strong>role power</strong>, <strong>relationships</strong>, and <strong>expertise</strong>.</p> | |||
<p>Understanding these kinds of power — how they’re built; how they’re wielded; ethically and otherwise; what they can and can’t accomplish — is key to understanding organizations at a systemic level and maximizing your effectiveness at work.</p> | |||
<h2 id="what-do-i-mean-by-power-and-why-are-am-i-talking-about-it">What do I mean by “power” and why are am I talking about it?</h2> | |||
<p>First, I should define what I mean by “power”. I use the term in a sense fairly close to its <a href="https://en.wikipedia.org/wiki/Power_(physics)">definition in physics</a>. In physics, power is “the amount of energy transferred … per unit of time”. More power means more work performed per unit of time; less power: less work. We can think about power in an organizational sense similarly: power, organizationally-speaking, is the ability to get more work done in a given unit of time. More colloquially, power is the ability to get shit done.</p> | |||
<p>For many, talking about power bluntly can feel gross. We tend to associate “power” with coercion or manipulation, but since the majority of folks are ethical and kind, we don’t love thinking about power. We especially don’t want to think about <em>our</em> power.</p> | |||
<p>However, there’s a reason why I include <a href="https://www.jofreeman.com/joreen/tyranny.htm">The Tyranny of Structurelessness</a> on <a href="https://jacobian.org/2018/may/2/engmanager-reading-list/">my list of required reading for new managers</a>: power exists within organizations whether we pay attention to it or not. Even in what Jo Freeman calls “structureless” organizations – what we’d now call “flat” organizations – power structures exist whether we want to think about them or our place in them or not.</p> | |||
<p>But power, at least from an organizational theory standpoint, isn’t about manipulation or getting people to do work they wouldn’t otherwise<sup id="fnref:1"></sup>. Power is an organizational system – the ability for the organization to get work done – that is vested in individuals (because organizations are made up of individuals). In healthy organizations, “power” manifests as a group of people, all aligned and doing their jobs, and all delivering value for the organization together. More on this thought in the section on <a href="#relationship-power">relationship power</a>.</p> | |||
<p>That’s why I think it’s important for everyone to understand how power exists and manifests inside organizations. Sociopaths already know this stuff, and use it to their advantage (and everyone elses’ detriments). I think it’s critical that empathetic, caring, ethical people understand power, too, so they can get stuff done in an empathetic, caring, ethical way.</p> | |||
<h2 id="role-power">Role Power</h2> | |||
<p>When we talk about power at work, this is probably the first thing that comes to mind. Role power is the power vested in you by your role – by your position on the org chart. Fundamentally, it’s the power of getting to use “we”: the power to speak on behalf of the organization. An individual contributor can’t say “we’re all getting new laptops” (well, they can, but it probably won’t happen); the CEO certainly can.</p> | |||
<p>Role power also manifests in the power to tell subordinates what to do. When your boss asks you to do something, there’s always an implicit “do this because I’m your boss” in that request. All else being equal, you’re more likely to do the thing if your boss asks than if someone else does.</p> | |||
<p>However, role power is limited – more limited than most people think. I would say that role power only accounts for maybe 20% of a person’s overall power organizationally<sup id="fnref:2"></sup>. Yes, a boss can, well, boss people around&mldr; but the effectiveness of this is quite limited. Orders lead to compliance, but not alignment; a manager who orders people around will get only the minimum out of their staff. They’ll be causing burnout and resentment, which will sooner or later cause that manager to fail.</p> | |||
<p>Further, there’s not that much that you can accomplish through role power alone. When I first became a manager, I had grand expectations about how much more I’d be able to get done. Our team had been struggling with a difficult technical transition: I thought our organization wasn’t making it a high enough priority, and I thought that people on the team were approaching the work poorly. I thought, “now that I’m the boss they’ll have to listen to me!”</p> | |||
<p>I was so wrong.</p> | |||
<p>I started ordering people around and arguing with my new peers on the management team. I didn’t quite get to the point of shouting “respect my authority!” – but I did get embarrassingly close to that. This didn’t just fail: it made the situation worse. My direct reports, who had respected me as a peer, lost that respect when I became their boss. My new peers, my fellow managers, stopped paying attention to me. I left the organization about a year later, tail between my legs.</p> | |||
<p>Role power is, somewhat contradictorily, more powerful the less you use it. If you get work done through other forms of power 99% of the time, when you <em>do</em> finally say “do this because I’m your boss”, it lands with force – and the relationship is strong enough to absorb that forcefulness. On the other hand, using role power too often damages relationships – and as we’ll see, relationship power is the most effective form of organizational power.</p> | |||
<p>Role power can only be built in one way: by getting promoted, moving up the org chart. This also diminishes its value: you can’t build role power unilaterally; you only have as much or as little as the org vests in you. It’s a fixed thing; the others are not.</p> | |||
<h2 id="relationship-power">Relationship Power</h2> | |||
<p>While role power is overemphasized, <strong>relationship power</strong> is often underestimated – but it’s by far the most effective sort of organizational power. If role power accounts for maybe 20% of someone’s total power, relationship power is something like 70%-80%.</p> | |||
<p>Relationship power is simply the ability to get work done through your relationships with others. It’s all the work that gets done because people and teams know and understand each other, work together effectively, and are happy to help each other out because they want others to be successful, too.</p> | |||
<p>If there’s one thing you take away from this article I hope it’s this: <strong>spend more time building relationships at work</strong>. If you build strong relationships with your colleagues, your work will be smoother, happier, and more effective.</p> | |||
<p>An example of how relationship power works:</p> | |||
<p>I’ve had several roles where I’ve been responsible for developing budgets. Each time, I’m usually the first among my peers to have my budget approved; it takes me mere days while my peers spend weeks or months going back and forth on their budgets. Is this because I’m just really good at budgets? Well, maybe – but more likely, it’s because I’ve laid the groundwork for a smooth approval far in advance. I’ve met everyone involved in the budget approval chain – a finance person or three, maybe our Head of Operations or COO. I get coffee with them, get to know them and their jobs, really understand what they’re looking for. I make sure they know that I’m happy to help them out in their jobs. Often, I can: if I develop a bit of light automation, or some Excel/Google Sheets macros, I can save finance folks boatloads of time.</p> | |||
<p>Importantly: I don’t do this because I’ll later need something from them! This isn’t a <a href="https://www.shmoop.com/quotes/someday-and-that-day-may-never-come.html">Don Corleone moment</a> – that would be ugly and manipulative. This is something I do with <em>all</em> the people I need to work with because I genuinely want to know and understand them and their jobs<sup id="fnref:3"></sup>. I offer to help because helping other people be more effective in their jobs is good for the whole organization (and it feels good to help, individually). Having a good relationship means working together is easy and effective, and I want that with everyone.</p> | |||
<p>So, when budget season comes, I find it pretty easy. My first draft will be far closer to done because I understand what the other stakeholders want and can anticipate some of their questions. Because we’ve already worked together, if there’s a problem they know it’ll be easy to pick up the phone and tell me about it.</p> | |||
<p>Importantly, relationship power functions <em>within</em> reporting chains too! Sure, you certainly are <em>allowed</em> to order a direct report to do something, but as I’ve noted above, this is ineffective. If instead, you understand your reports well – what they like, what they don’t, what motivates them – and they understand you and the team – what you need, what success looks like for the team, how the team’s work fits into the greater org – you can ask them for work within that context and they’ll be happy to do it. You might not even need to ask; they might just know!</p> | |||
<p>This is why empathy and emotional intelligence are such critical skills for managers: understanding other people, being able to reason about how they think and what motivates them, and genuinely caring about their well-being all make it easier to work with them to get things done.</p> | |||
<p>You build relationship power by&mldr; building relationships. This begins with talking to them. There’s a reason why one-on-ones are <em>the</em> cornerstone of good management practice: 1:1s mean scheduled time for building relationships. Regular 1:1s lead to better relationships and this builds relationship power for both the manager and the report!</p> | |||
<p>You also build relationship power outside your reporting chain through talking to folks – regular meetings, coffee breaks, chats over lunch, and so forth. In <a href="https://www.amazon.com/dp/B015VACHOK">High Output Management</a> (one of the all-time best management books), Andy Grove writes about how much time he spends simply walking around and talking to people. It can seem surprising that an executive would spend so much time just listening, but</p> | |||
<blockquote><p>It’s obvious that your decision-making depends finally on how well you comprehend the facts and issues facing your business. This is why information-gathering is so important in a manager’s life. Other activities—conveying information, making decisions, and being a role model for your subordinates—are all governed by the base of information that you, the manager, have about the tasks, the issues, the needs, and the problems facing your organization. <strong>In short, information-gathering is the basis of all other managerial work, which is why I choose to spend so much of my day doing it.</strong></p></blockquote> | |||
<p>(Emphasis mine.)</p> | |||
<p>You also build relationship power every time you work with someone (assuming you do a good job, of course). This doesn’t necessarily mean doing favors – relationship power isn’t a Machiavellian quid pro quo – it’s simply that when you accomplish something with other people, that relationship gets stronger. One weird thing I’ve found is that sometimes <em>asking for help</em> can build a relationship faster than offering it. Most people want to help their colleagues, and being open about where you’re struggling is a great way to show that it’s safe for them to open up to you.</p> | |||
<h2 id="expertise-power">Expertise Power</h2> | |||
<p>Finally, expertise power. Expertise power is the power you have at an organization by being a clear expert in some technology, system, or process. It’s the power that a person (or team) has because they know or understand something better than everyone.</p> | |||
<p>I have less to say about expertise power than the previous two, mostly because I’ve rarely worked for organizations or in roles where it’s been all that useful<sup id="fnref:4"></sup>. Expertise power is something typically that Staff- or Principal-level engineers have. These positions don’t have the same role power as managers. Both managers and very senior <abbr title="individual contributors">ICs</abbr> fundamentally use relationship power to get stuff done, but senior <abbr title="individual contributors">ICs</abbr> augment that with expertise power rather than role power.</p> | |||
<p>If you’re interested in learning more about how expertise functions within these sorts of senior <abbr title="individual contributor">ICs</abbr> roles, I suggest Will Larson’s book <a href="https://staffeng.com/book">Staff Engineer: Leadership beyond the management track</a>.</p> | |||
<h2 id="conclusion">Conclusion</h2> | |||
<p>Learning to think about organizational power was transformative for my career. Suddenly, I was able to understand why some projects got done – and others withered on the vine. Understanding <em>why</em> relationships are so important helped me make sure I prioritized them appropriately. I doubt I’d be the leader I am today without gaining this understanding. I hope it likewise helps you in your career!</p> | |||
</article> | |||
<hr> | |||
<footer> | |||
<p> | |||
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use> | |||
</svg> Accueil</a> • | |||
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-rss2"></use> | |||
</svg> Suivre</a> • | |||
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-user-tie"></use> | |||
</svg> Pro</a> • | |||
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-mail"></use> | |||
</svg> Email</a> • | |||
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-hammer2"></use> | |||
</svg> Légal</abbr> | |||
</p> | |||
<template id="theme-selector"> | |||
<form> | |||
<fieldset> | |||
<legend><svg class="icon icon-brightness-contrast"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-brightness-contrast"></use> | |||
</svg> Thème</legend> | |||
<label> | |||
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
</label> | |||
<label> | |||
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
</label> | |||
<label> | |||
<input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
</label> | |||
</fieldset> | |||
</form> | |||
</template> | |||
</footer> | |||
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script> | |||
<script> | |||
function loadThemeForm(templateName) { | |||
const themeSelectorTemplate = document.querySelector(templateName) | |||
const form = themeSelectorTemplate.content.firstElementChild | |||
themeSelectorTemplate.replaceWith(form) | |||
form.addEventListener('change', (e) => { | |||
const chosenColorScheme = e.target.value | |||
localStorage.setItem('theme', chosenColorScheme) | |||
toggleTheme(chosenColorScheme) | |||
}) | |||
const selectedTheme = localStorage.getItem('theme') | |||
if (selectedTheme && selectedTheme !== 'undefined') { | |||
form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
} | |||
} | |||
const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
window.addEventListener('load', () => { | |||
let hasDarkRules = false | |||
for (const styleSheet of Array.from(document.styleSheets)) { | |||
let mediaRules = [] | |||
for (const cssRule of styleSheet.cssRules) { | |||
if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
continue | |||
} | |||
// WARNING: Safari does not have/supports `conditionText`. | |||
if (cssRule.conditionText) { | |||
if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
continue | |||
} | |||
} else { | |||
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
continue | |||
} | |||
} | |||
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
} | |||
// WARNING: do not try to insert a Rule to a styleSheet you are | |||
// currently iterating on, otherwise the browser will be stuck | |||
// in a infinite loop… | |||
for (const mediaRule of mediaRules) { | |||
styleSheet.insertRule(mediaRule.cssText) | |||
hasDarkRules = true | |||
} | |||
} | |||
if (hasDarkRules) { | |||
loadThemeForm('#theme-selector') | |||
} | |||
}) | |||
</script> | |||
</body> | |||
</html> |
@@ -0,0 +1,345 @@ | |||
<!doctype html><!-- This is a valid HTML5 document. --> | |||
<!-- Screen readers, SEO, extensions and so on. --> | |||
<html lang="fr"> | |||
<!-- Has to be within the first 1024 bytes, hence before the `title` element | |||
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
<meta charset="utf-8"> | |||
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
<!-- The viewport meta is quite crowded and we are responsible for that. | |||
See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
<meta name="viewport" content="width=device-width,initial-scale=1"> | |||
<!-- Required to make a valid HTML5 document. --> | |||
<title>Frugal computing (archive) — David Larlet</title> | |||
<meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
<!-- That good ol' feed, subscribe :). --> | |||
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
<!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
<link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
<meta name="msapplication-TileColor" content="#f7f7f7"> | |||
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)"> | |||
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)"> | |||
<!-- Documented, feel free to shoot an email. --> | |||
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css"> | |||
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
<script> | |||
function toggleTheme(themeName) { | |||
document.documentElement.classList.toggle( | |||
'forced-dark', | |||
themeName === 'dark' | |||
) | |||
document.documentElement.classList.toggle( | |||
'forced-light', | |||
themeName === 'light' | |||
) | |||
} | |||
const selectedTheme = localStorage.getItem('theme') | |||
if (selectedTheme !== 'undefined') { | |||
toggleTheme(selectedTheme) | |||
} | |||
</script> | |||
<meta name="robots" content="noindex, nofollow"> | |||
<meta content="origin-when-cross-origin" name="referrer"> | |||
<!-- Canonical URL for SEO purposes --> | |||
<link rel="canonical" href="https://wimvanderbauwhede.github.io/articles/frugal-computing/"> | |||
<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all"> | |||
<article> | |||
<header> | |||
<h1>Frugal computing</h1> | |||
</header> | |||
<nav> | |||
<p class="center"> | |||
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use> | |||
</svg> Accueil</a> • | |||
<a href="https://wimvanderbauwhede.github.io/articles/frugal-computing/" title="Lien vers le contenu original">Source originale</a> | |||
</p> | |||
</nav> | |||
<hr> | |||
<p>On the need for low-carbon and sustainable computing and the path towards zero-carbon computing.</p> | |||
<h2>Key points</h2> | |||
<h3>The problem:</h3> | |||
<ul> | |||
<li>The current emissions from computing are about 2% of the world total but are projected to rise steeply over the next two decades. By 2040 emissions from computing alone will be close to half the emissions level acceptable to keep global warming below 1.5°C. This growth in computing emissions is unsustainable: it would make it virtually impossible to meet the emissions warming limit.</li> | |||
<li>The emissions from production of computing devices far exceed the emissions from operating them, so even if devices are more energy efficient producing more of them will make the emissions problem worse. Therefore we must extend the useful life of our computing devices.</li> | |||
</ul> | |||
<h3>The solution:</h3> | |||
<ul> | |||
<li>As a society we need to start treating computational resources as finite and precious, to be utilised only when necessary, and as effectively as possible. We need <em>frugal computing</em>: achieving the same results for less energy. </li> | |||
</ul> | |||
<h3>The vision:</h3> | |||
<ul> | |||
<li>Imagine we can extend the useful life of our devices and even increase their capabilities without any increase in energy consumption.</li> | |||
<li>Meanwhile, we will develop the technologies for the next generation of devices, designed for energy efficiency as well as long life.</li> | |||
<li>Every subsequent cycle will last longer, until finally the world will have computing resources that last forever and hardly use any energy.</li> | |||
</ul> | |||
<h2>Defining computational resources</h2> | |||
<p>Computational resources are all resources of energy and material that are involved in any given task that requires computing. For example, when you perform a web search on your phone or participate in a video conference on your laptop, the computational resources involved are those for production and running of your phone or laptop, the mobile network or WiFi you are connected to, the fixed network it connects to, the data centres that perform the search or video delivery operations. If you are a scientist running a simulator in a supercomputer, then the computational resources involved are your desktop computer, the network and the supercomputer. For an industrial process control system, it is the production and operation of the Programmable Logic Controllers.</p> | |||
<h2>Computational resources are finite</h2> | |||
<p>Since the start of general purpose computing in the 1970s, our society has been using increasing amounts of computational resources. </p> | |||
<p>For a long time the growth in computational capability as a function of device power consumption has literally been exponential, a trend expressed by <a href="https://www.britannica.com/technology/Moores-law">Moore's law</a>. </p> | |||
<p>With this growth in computational capability, increasing use of computational resources has become pervasive in today's society. Until recently, the total energy budget and carbon footprint resulting from the use of computational resources has been small compared to the world total. As a result, computational resources have until recently effectively been treated as unlimited. </p> | |||
<p>Because of this, the economics of hardware and software development have been built on the assumption that with every generation, performance would double for free. Now, this unlimited growth is no longer sustainable because of a combination of technological limitations and the climate emergency. Therefore, we need to do more with less. </p> | |||
<p>Moore's law has effectively come to an end as integrated circuits can't be scaled down any more. As a result, the performance per Watt is no longer increasing exponentially. On the other hand, the demand for computational resources is set to increase considerably. </p> | |||
<p>The consequence is that at least for the next decades, growth in demand for computational resources will not be offset by increased power efficiency. Therefore with business as usual, the total energy budget and carbon footprint resulting from the use of computational resources will grow dramatically to become a major contributor to the world total.</p> | |||
<p>Furthermore, the resources required to create the compute devices and infrastructure are also finite, and the total energy budget and carbon footprint of production of compute devices is huge. Moore's Law has conditioned us to doubling of performance ever two years, which has led to very short effective lifetimes of compute hardware. This rate of obsolescence of compute devices and software is entirely unsustainable. </p> | |||
<p>Therefore, as a society we need to start treating computational resources as finite and precious, to be utilised only when necessary, and as frugally as possible. And as computing scientists, we need to ensure that computing has the lowest possible energy consumption. And we should achieve this with the currently available technologies because the lifetimes of compute devices needs to be extended dramatically. </p> | |||
<p>I would like to call this "frugal computing": achieving the same results for less energy by being more frugal with our computing resources. </p> | |||
<h2>The scale of the problem</h2> | |||
<h3>Meeting the climate targets</h3> | |||
<p>To limit global warming to 1.5°C, within the next decade a global reduction from 55 gigatonnes CO₂ equivalent (GtCO₂e) by 32 GtCO₂e to 23 GtCO₂e per year is needed <a href="#5">[5]</a>. So by 2030 that would mean a necessary reduction in overall CO₂ emissions of more than 50%. According to the International Energy Agency <a href="#10">[10]</a>, emissions from electricity are currently estimated at about 10 GtCO₂e. The global proportion of electricity from renewables is projected to rise from the current figure of 22% to slightly more than 30% by 2040 <a href="#15">[15]</a>. In other words, we cannot count on renewables to eliminate CO₂ emissions from electricity in time to meet the climate targets. Reducing the energy consumption is the only option. </p> | |||
<h3>Emissions from consumption of computational resources</h3> | |||
<p>The consequence of the end of Moore's law was expressed most dramatically in a 2015 report by the Semiconductor Industry Association (SIA) "Rebooting the IT Revolution: a call to action" <a href="#1">[1]</a>, which calculated that, based on projected growth rates and on the 2015 ITRS roadmap for CMOS chip engineering technologies <a href="#16">[16]</a>, </p> | |||
<blockquote> | |||
<p>computing will not be sustainable by 2040, when the energy required for computing will exceed the estimated world's energy production. </p> | |||
</blockquote> | |||
<p>It must be noted that this is purely the energy of the computing device, as explained in the report. The energy required by e.g. the data centre infrastructure and the network is not included. </p> | |||
<p>The SIA has reiterated this in their 2020 "Decadal Plan for Semiconductors" <a href="#2">[2]</a>, although they have revised the projection based on a "market dynamics argument": </p> | |||
<blockquote> | |||
<p>If the exponential growth in compute energy is left unchecked, market dynamics will limit the growth of the computational capacity which would cause a flattening out the energy curve. </p> | |||
</blockquote> | |||
<p>This is merely an acknowledgement of the reality that the world's energy production is not set to rise dramatically, and therefore increased demand will result in higher prices which will damp the demand. So computation is not actually going to exceed the world's energy production.</p> | |||
<blockquote> | |||
<p>Ever-rising energy demand for computing vs. global energy production is creating new risk, and new computing paradigms offer opportunities to dramatically improve energy efficiency.</p> | |||
</blockquote> | |||
<p>In the countries where most of the computational resources are consumed (US and EU), electricity production accounts currently for 25% of the total emissions <a href="#4">[4]</a>. According to the SIA's estimates, computation accounts currently for a little less than 10% of the total electricity production but is set to rise to about 30% by 2040. This would mean that, with business as usual, computational resources would be responsible for at least 10% of all global CO₂ emissions by 2040. </p> | |||
<p>The independent study "Assessing ICT global emissions footprint: Trends to 2040 & recommendations" <a href="#3">[3]</a> corroborates the SIA figures: they estimate the computing greenhouse gas emissions for 2020 between 3.0% and 3.5% of the total, which is a bit higher than the SIA estimate of 2.5% because it does take into account networks and datacentres. Their projection for 2040 is 14% rather than 10%, which means a growth of 4x rather than 3x. </p> | |||
<p>To put it in absolute values, based on the above estimate, by 2040 energy consumption of compute devices would be responsible for 5 GtCO₂e, whereas the target for world total emissions from all sources is 23 GtCO₂e.</p> | |||
<h3>Emissions from production of computational resources</h3> | |||
<p>To make matters worse, the carbon emissions resulting from the production of computing devices exceeds those incurred during operation. This is a crucial point, because it means that we can't rely on next-generation hardware technologies to save energy: the production of this next generation of devices will create more emissions than any operational gains can offset. It does not mean research into more efficient technologies should stop. But their deployment cycles should be much slower. Extending the useful life of compute technologies must become our priority.</p> | |||
<p>The report about the cost of planned obsolescence by the European Environmental Bureau <a href="#7">[7]</a> makes the scale of the problem very clear. For laptops and similar computers, manufacturing, distribution and disposal account for 52% of their <a href="https://www.sciencedirect.com/topics/earth-and-planetary-sciences/global-warming-potential">Global Warming Potential</a> (i.e. the amount of CO₂-equivalent emissions caused). For mobile phones, this is 72%. The report calculates that the lifetime of these devices should be at least 25 years to limit their Global Warming Potential. Currently, for laptops it is about 5 years and for mobile phones 3 years. According to <a href="#8">[8]</a>, the typical lifetime for servers in data centres is also 3-5 years, which again falls short of these minimal requirements. According to this paper, the impact of manufacturing of the servers is 20% of the total, which would require an extension of the useful life to 11-18 years. </p> | |||
<h3>The total emissions cost from computing</h3> | |||
<p>Taking into account the carbon cost of both operation and production, computing would be responsible for 10 GtCO₂e by 2040, almost half of the acceptable CO₂ emissions budget <a href="#2">[2,3,14]</a>.</p> | |||
<figure> | |||
<img src="https://wimvanderbauwhede.github.io/images/computing-emissions.png" alt="A graph with two bars: world emissions (55) and emissions from computing (0.1) in 2020; and for 2040, the world emissions target to limit warming to 1.5°C (23), and the projected emissions from computing (10)" title="A graph with two bars: world emissions (55) and emissions from computing (0.1) in 2020; and for 2040, the world emissions target to limit warming to 1.5°C (23), and the projected emissions from computing (10)"> | |||
<figcaption>Actual and projected emissions from computing (production+operation), and 2040 emission target to limit warming to <2°C</figcaption> | |||
</figure> | |||
<h3>A breakdown per device type</h3> | |||
<p>To decide on the required actions to reduce emissions, it is important to look at the numbers of different types of devices and their energy usage. If we consider mobile phones as one category, laptops and desktops as another and servers as a third category, the questions are: how many devices are there in each category, and what is their energy consumption. The absolute numbers of devices in use are quite difficult to estimate, but the yearly sales figures <a href="#10">[10]</a> and estimates for the energy consumption for each category <a href="#11">[11,12,13,14]</a> are readily available from various sources. The tables below show the 2020 sales and yearly energy consumption estimates for each category of devices. A detailed analysis is presented in <a href="#14">[14]</a>.</p> | |||
<table> | |||
<caption>Number of devices sold worldwide in 2020</caption> | |||
<tr><th>Device type</th><th>2020 sales</th></tr> | |||
<tr><td>Phones</td><td> 3000M</td></tr> | |||
<tr><td>Servers</td><td> 13M</td></tr> | |||
<tr><td>Tablets</td><td> 160M</td></tr> | |||
<tr><td>Displays</td><td> 40M</td></tr> | |||
<tr><td>Laptops</td><td> 280M</td></tr> | |||
<tr><td>Desktops</td><td> 80M</td></tr> | |||
<tr><td>TVs</td><td>220M</td></tr> | |||
<tr><td>IoT devices</td><td> 2000M</td></tr> | |||
</table> | |||
<p>The energy consumption of all communication and computation technology currently in use in the world is currently around 3,000 TWh, about 11% of the world's electricity consumption, projected to rise by 3-4 times by 2040 with business as usual according to <a href="#2">[2]</a>. This is a conservative estimate: the study in <a href="#14">[14]</a> includes a worst-case projection of a rise to 30,000 TWh (exceeding the current world electricity consumption) by 2030. </p> | |||
<table> | |||
<caption>Yearly energy consumption estimates in TWh</caption> | |||
<tr><th>Device type</th><th>TWh</th></tr> | |||
<tr><td>TVs</td><td> 560</td></tr> | |||
<tr><td>Other Consumer devices</td><td> 240</td></tr> | |||
<tr><td>Fixed access network (wired+WiFi)</td><td> 900 + 500</td></tr> | |||
<tr><td>Mobile network</td><td> 100</td></tr> | |||
<tr><td>Data centres</td><td> 700</td></tr> | |||
<tr><td>Total</td><td> 3000</td></tr> | |||
</table> | |||
<p>The above data make it clear which actions are necessary: the main carbon cost of phones, tablets and IoT devices is their production and the use of the mobile network, so we must extend their useful life very considerably and reduce network utilisation. Extending the life time is also the key action for datacentres and desktop computers, but their energy consumption also needs to be reduced considerably, as does the energy consumption of the wired, WiFi and mobile networks. </p> | |||
<h2>A vision for low carbon and sustainable computing</h2> | |||
<p>It is clear that urgent action is needed: in less than two decades, the global use of computational resources needs to be transformed radically. Otherwise, the world will fail to meet its climate targets, even with significant reductions in other emission areas. The carbon cost of both production and operation of the devices must be considerably reduced. </p> | |||
<p>To use devices for longer, a change in business models as well as consumer attitudes is needed. This requires raising awareness and education but also providing incentives for behavioural change. And to support devices for a long time, an infrastructure for repair and maintenance is needed, with long-term availability of parts, open repair manuals and training. To make all this happen, economic incentives and policies will be needed (e.g. taxation, regulation). Therefore we need to convince key decision makers in society, politics and business.</p> | |||
<p>Imagine that we can extend the useful life of our devices and even increase their capabilities, purely through better computing science. With every improvement, the computational capacity will in effect increase without any increase in energy consumption. Meanwhile, we will develop the technologies for the next generation of devices, designed for energy efficiency as well as long life. Every subsequent cycle will last longer, until finally the world will have computing resources that last forever and hardly use any energy.</p> | |||
<figure> | |||
<img src="https://wimvanderbauwhede.github.io/images/towards-zero-carbon-computing.png" alt="A graph with four trends: emissions from production, emissions in total, performance and emissions/performance." title="A graph with four trends: emissions from production, emissions in total, performance and emissions/performance."> | |||
<figcaption>Towards zero carbon computing: increasing performance and lifetime and reducing emissions. Illustration with following assumptions: every new generation lasts twice as long as the previous one and cost half as much energy to produce; energy efficiency improves linearly with 5% per year.</figcaption> | |||
</figure> | |||
<p>This is a very challenging vision, spanning all aspects of computing science. To name just a few challenges:</p> | |||
<ul> | |||
<li>We must design software so that it supports devices with extended lifetimes.</li> | |||
<li>We need software engineering strategies to handle the extended software life cycles, and in particular deal with <a href="https://en.wikipedia.org/wiki/Technical_debt">technical debt</a>.</li> | |||
<li>Longer life means more opportunities to exploit vulnerabilities, so we need better cyber security.</li> | |||
<li>We need to develop new approaches to reduce overall energy consumption across the entire system.</li> | |||
</ul> | |||
<p>To address these challenges, action is needed on many fronts. What will you do to make frugal computing a reality?</p> | |||
<h2>References</h2> | |||
<p><small> | |||
<span id="1">[1] <a href="https://www.semiconductors.org/resources/rebooting-the-it-revolution-a-call-to-action-2/"><em>"Rebooting the IT revolution: a call to action"</em>, Semiconductor Industry Association/Semiconductor Research Corporation, Sept 2015</a></span><br> | |||
<span id="2">[2] <a href="https://www.src.org/about/decadal-plan/decadal-plan-full-report.pdf"><em>"Full Report for the Decadal Plan for Semiconductors"</em>, Semiconductor Industry Association/Semiconductor Research Corporation, Jan 2021</a></span><br> | |||
<span id="3">[3] <a href="https://www.sciencedirect.com/science/article/pii/S095965261733233X"><em>"Assessing ICT global emissions footprint: Trends to 2040 & recommendations"</em>, Lotfi Belkhir, Ahmed Elmeligi, Journal of Cleaner Production 177 (2018) 448--463</a></span><br> | |||
<span id="4">[4] <a href="https://www.epa.gov/ghgemissions/sources-greenhouse-gas-emissions"><em>"Sources of Greenhouse Gas Emissions"</em>, United States Environmental Protection Agency</a>, Last updated on April 14, 2021</span><br> | |||
<span id="5">[5] <a href="https://www.unep.org/emissions-gap-report-2020"><em>"Emissions Gap Report 2020"</em>, UN Environment Programme, December 2020</a></span><br> | |||
<span id="6">[6] <a href="https://onlinelibrary.wiley.com/doi/full/10.1111/jiec.13123"><em>"The link between product service lifetime and GHG emissions: A comparative study for different consumer products"</em>, Simon Glöser-Chahoud, Matthias Pfaff, Frank Schultmann, Journal of Industrial Ecology, 25 (2), pp 465-478, March 2021</a></span><br> | |||
<span id="7">[7] <a href="https://eeb.org/library/coolproducts-report/"><em>"Cool products don’t cost the Earth – Report"</em>, European Environmental Bureau, September 2019</a></span><br> | |||
<span id="8">[8] <a href="https://link.springer.com/article/10.1007/s11367-014-0838-7"><em>"The life cycle assessment of a UK data centre"</em>, Beth Whitehead, Deborah Andrews, Amip Shah, Graeme Maidment, Building and Environment 93 (2015) 395--405, January 2015</a></span><br> | |||
<span id="9">[9] <a href="https://www.statista.com">Statista</a>, retrieved June 2021</span><br> | |||
<span id="10">[10] <a href="https://www.iea.org/reports/global-energy-CO%E2%82%82-status-report-2019/emissions"><em>"Global Energy & CO₂ Status Report"</em>, International Energy Agency, March 2019</a></span><br> | |||
<span id="11">[11] <a href="https://link.springer.com/article/10.1007/s11367-015-0909-4"><em>"Redefining scope: the true environmental impact of smartphones?"</em>, James Suckling, Jacquetta Lee, The International Journal of Life Cycle Assessment volume 20, pages 1181–1196 (2015)</a></span><br> | |||
<span id="12">[12] <a href="https://www.racksolutions.com/news/blog/server-rack-power-consumption-calculator/"><em>"Server Rack Power Consumption Calculator"</em>, Rack Solutions, Inc., July 2019</a></span><br> | |||
<span id="13">[13] <a href="https://www.sciencedirect.com/science/article/pii/S111001682030524X"><em>"Analysis of energy consumption and potential energy savings of an institutional building in Malaysia"</em>, Siti Birkha Mohd Ali, M.Hasanuzzaman, N.A.Rahim, M.A.A.Mamun, U.H.Obaidellah, Alexandria Engineering Journal, Volume 60, Issue 1, February 2021, Pages 805-820</a></span><br> | |||
<span id="14">[14] <a href="https://doi.org/10.3390/challe6010117"><em>"On Global Electricity Usage of Communication Technology: Trends to 2030"</em>, Anders S. G. Andrae, Tomas Edler, Challenges 2015, 6(1), 117-157 </a></span><br> | |||
<span id="15">[15] <a href="https://www.bp.com/en/global/corporate/energy-economics/energy-outlook.html"><em>"BP Energy Outlook: 2020 Edition"</em>,BP plc</a></span><br> | |||
<span id="16">[16] <a href="https://www.semiconductors.org/resources/2015-international-technology-roadmap-for-semiconductors-itrs/"><em>"2015 International Technology Roadmap for Semiconductors (ITRS)"</em>, Semiconductor Industry Association, June 2015</a></span><br> | |||
</small></p> | |||
</article> | |||
<hr> | |||
<footer> | |||
<p> | |||
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use> | |||
</svg> Accueil</a> • | |||
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-rss2"></use> | |||
</svg> Suivre</a> • | |||
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-user-tie"></use> | |||
</svg> Pro</a> • | |||
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-mail"></use> | |||
</svg> Email</a> • | |||
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-hammer2"></use> | |||
</svg> Légal</abbr> | |||
</p> | |||
<template id="theme-selector"> | |||
<form> | |||
<fieldset> | |||
<legend><svg class="icon icon-brightness-contrast"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-brightness-contrast"></use> | |||
</svg> Thème</legend> | |||
<label> | |||
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
</label> | |||
<label> | |||
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
</label> | |||
<label> | |||
<input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
</label> | |||
</fieldset> | |||
</form> | |||
</template> | |||
</footer> | |||
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script> | |||
<script> | |||
function loadThemeForm(templateName) { | |||
const themeSelectorTemplate = document.querySelector(templateName) | |||
const form = themeSelectorTemplate.content.firstElementChild | |||
themeSelectorTemplate.replaceWith(form) | |||
form.addEventListener('change', (e) => { | |||
const chosenColorScheme = e.target.value | |||
localStorage.setItem('theme', chosenColorScheme) | |||
toggleTheme(chosenColorScheme) | |||
}) | |||
const selectedTheme = localStorage.getItem('theme') | |||
if (selectedTheme && selectedTheme !== 'undefined') { | |||
form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
} | |||
} | |||
const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
window.addEventListener('load', () => { | |||
let hasDarkRules = false | |||
for (const styleSheet of Array.from(document.styleSheets)) { | |||
let mediaRules = [] | |||
for (const cssRule of styleSheet.cssRules) { | |||
if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
continue | |||
} | |||
// WARNING: Safari does not have/supports `conditionText`. | |||
if (cssRule.conditionText) { | |||
if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
continue | |||
} | |||
} else { | |||
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
continue | |||
} | |||
} | |||
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
} | |||
// WARNING: do not try to insert a Rule to a styleSheet you are | |||
// currently iterating on, otherwise the browser will be stuck | |||
// in a infinite loop… | |||
for (const mediaRule of mediaRules) { | |||
styleSheet.insertRule(mediaRule.cssText) | |||
hasDarkRules = true | |||
} | |||
} | |||
if (hasDarkRules) { | |||
loadThemeForm('#theme-selector') | |||
} | |||
}) | |||
</script> | |||
</body> | |||
</html> |
@@ -0,0 +1,178 @@ | |||
title: Frugal computing | |||
url: https://wimvanderbauwhede.github.io/articles/frugal-computing/ | |||
hash_url: 710f8cdebd7560223ebd378f9cbe7822 | |||
<p>On the need for low-carbon and sustainable computing and the path towards zero-carbon computing.</p> | |||
<h2>Key points</h2> | |||
<h3>The problem:</h3> | |||
<ul> | |||
<li>The current emissions from computing are about 2% of the world total but are projected to rise steeply over the next two decades. By 2040 emissions from computing alone will be close to half the emissions level acceptable to keep global warming below 1.5°C. This growth in computing emissions is unsustainable: it would make it virtually impossible to meet the emissions warming limit.</li> | |||
<li>The emissions from production of computing devices far exceed the emissions from operating them, so even if devices are more energy efficient producing more of them will make the emissions problem worse. Therefore we must extend the useful life of our computing devices.</li> | |||
</ul> | |||
<h3>The solution:</h3> | |||
<ul> | |||
<li>As a society we need to start treating computational resources as finite and precious, to be utilised only when necessary, and as effectively as possible. We need <em>frugal computing</em>: achieving the same results for less energy. </li> | |||
</ul> | |||
<h3>The vision:</h3> | |||
<ul> | |||
<li>Imagine we can extend the useful life of our devices and even increase their capabilities without any increase in energy consumption.</li> | |||
<li>Meanwhile, we will develop the technologies for the next generation of devices, designed for energy efficiency as well as long life.</li> | |||
<li>Every subsequent cycle will last longer, until finally the world will have computing resources that last forever and hardly use any energy.</li> | |||
</ul> | |||
<h2>Defining computational resources</h2> | |||
<p>Computational resources are all resources of energy and material that are involved in any given task that requires computing. For example, when you perform a web search on your phone or participate in a video conference on your laptop, the computational resources involved are those for production and running of your phone or laptop, the mobile network or WiFi you are connected to, the fixed network it connects to, the data centres that perform the search or video delivery operations. If you are a scientist running a simulator in a supercomputer, then the computational resources involved are your desktop computer, the network and the supercomputer. For an industrial process control system, it is the production and operation of the Programmable Logic Controllers.</p> | |||
<h2>Computational resources are finite</h2> | |||
<p>Since the start of general purpose computing in the 1970s, our society has been using increasing amounts of computational resources. </p> | |||
<p>For a long time the growth in computational capability as a function of device power consumption has literally been exponential, a trend expressed by <a href="https://www.britannica.com/technology/Moores-law">Moore's law</a>. </p> | |||
<p>With this growth in computational capability, increasing use of computational resources has become pervasive in today's society. Until recently, the total energy budget and carbon footprint resulting from the use of computational resources has been small compared to the world total. As a result, computational resources have until recently effectively been treated as unlimited. </p> | |||
<p>Because of this, the economics of hardware and software development have been built on the assumption that with every generation, performance would double for free. Now, this unlimited growth is no longer sustainable because of a combination of technological limitations and the climate emergency. Therefore, we need to do more with less. </p> | |||
<p>Moore's law has effectively come to an end as integrated circuits can't be scaled down any more. As a result, the performance per Watt is no longer increasing exponentially. On the other hand, the demand for computational resources is set to increase considerably. </p> | |||
<p>The consequence is that at least for the next decades, growth in demand for computational resources will not be offset by increased power efficiency. Therefore with business as usual, the total energy budget and carbon footprint resulting from the use of computational resources will grow dramatically to become a major contributor to the world total.</p> | |||
<p>Furthermore, the resources required to create the compute devices and infrastructure are also finite, and the total energy budget and carbon footprint of production of compute devices is huge. Moore's Law has conditioned us to doubling of performance ever two years, which has led to very short effective lifetimes of compute hardware. This rate of obsolescence of compute devices and software is entirely unsustainable. </p> | |||
<p>Therefore, as a society we need to start treating computational resources as finite and precious, to be utilised only when necessary, and as frugally as possible. And as computing scientists, we need to ensure that computing has the lowest possible energy consumption. And we should achieve this with the currently available technologies because the lifetimes of compute devices needs to be extended dramatically. </p> | |||
<p>I would like to call this "frugal computing": achieving the same results for less energy by being more frugal with our computing resources. </p> | |||
<h2>The scale of the problem</h2> | |||
<h3>Meeting the climate targets</h3> | |||
<p>To limit global warming to 1.5°C, within the next decade a global reduction from 55 gigatonnes CO₂ equivalent (GtCO₂e) by 32 GtCO₂e to 23 GtCO₂e per year is needed <a href="#5">[5]</a>. So by 2030 that would mean a necessary reduction in overall CO₂ emissions of more than 50%. According to the International Energy Agency <a href="#10">[10]</a>, emissions from electricity are currently estimated at about 10 GtCO₂e. The global proportion of electricity from renewables is projected to rise from the current figure of 22% to slightly more than 30% by 2040 <a href="#15">[15]</a>. In other words, we cannot count on renewables to eliminate CO₂ emissions from electricity in time to meet the climate targets. Reducing the energy consumption is the only option. </p> | |||
<h3>Emissions from consumption of computational resources</h3> | |||
<p>The consequence of the end of Moore's law was expressed most dramatically in a 2015 report by the Semiconductor Industry Association (SIA) "Rebooting the IT Revolution: a call to action" <a href="#1">[1]</a>, which calculated that, based on projected growth rates and on the 2015 ITRS roadmap for CMOS chip engineering technologies <a href="#16">[16]</a>, </p> | |||
<blockquote> | |||
<p>computing will not be sustainable by 2040, when the energy required for computing will exceed the estimated world's energy production. </p> | |||
</blockquote> | |||
<p>It must be noted that this is purely the energy of the computing device, as explained in the report. The energy required by e.g. the data centre infrastructure and the network is not included. </p> | |||
<p>The SIA has reiterated this in their 2020 "Decadal Plan for Semiconductors" <a href="#2">[2]</a>, although they have revised the projection based on a "market dynamics argument": </p> | |||
<blockquote> | |||
<p>If the exponential growth in compute energy is left unchecked, market dynamics will limit the growth of the computational capacity which would cause a flattening out the energy curve. </p> | |||
</blockquote> | |||
<p>This is merely an acknowledgement of the reality that the world's energy production is not set to rise dramatically, and therefore increased demand will result in higher prices which will damp the demand. So computation is not actually going to exceed the world's energy production.</p> | |||
<blockquote> | |||
<p>Ever-rising energy demand for computing vs. global energy production is creating new risk, and new computing paradigms offer opportunities to dramatically improve energy efficiency.</p> | |||
</blockquote> | |||
<p>In the countries where most of the computational resources are consumed (US and EU), electricity production accounts currently for 25% of the total emissions <a href="#4">[4]</a>. According to the SIA's estimates, computation accounts currently for a little less than 10% of the total electricity production but is set to rise to about 30% by 2040. This would mean that, with business as usual, computational resources would be responsible for at least 10% of all global CO₂ emissions by 2040. </p> | |||
<p>The independent study "Assessing ICT global emissions footprint: Trends to 2040 & recommendations" <a href="#3">[3]</a> corroborates the SIA figures: they estimate the computing greenhouse gas emissions for 2020 between 3.0% and 3.5% of the total, which is a bit higher than the SIA estimate of 2.5% because it does take into account networks and datacentres. Their projection for 2040 is 14% rather than 10%, which means a growth of 4x rather than 3x. </p> | |||
<p>To put it in absolute values, based on the above estimate, by 2040 energy consumption of compute devices would be responsible for 5 GtCO₂e, whereas the target for world total emissions from all sources is 23 GtCO₂e.</p> | |||
<h3>Emissions from production of computational resources</h3> | |||
<p>To make matters worse, the carbon emissions resulting from the production of computing devices exceeds those incurred during operation. This is a crucial point, because it means that we can't rely on next-generation hardware technologies to save energy: the production of this next generation of devices will create more emissions than any operational gains can offset. It does not mean research into more efficient technologies should stop. But their deployment cycles should be much slower. Extending the useful life of compute technologies must become our priority.</p> | |||
<p>The report about the cost of planned obsolescence by the European Environmental Bureau <a href="#7">[7]</a> makes the scale of the problem very clear. For laptops and similar computers, manufacturing, distribution and disposal account for 52% of their <a href="https://www.sciencedirect.com/topics/earth-and-planetary-sciences/global-warming-potential">Global Warming Potential</a> (i.e. the amount of CO₂-equivalent emissions caused). For mobile phones, this is 72%. The report calculates that the lifetime of these devices should be at least 25 years to limit their Global Warming Potential. Currently, for laptops it is about 5 years and for mobile phones 3 years. According to <a href="#8">[8]</a>, the typical lifetime for servers in data centres is also 3-5 years, which again falls short of these minimal requirements. According to this paper, the impact of manufacturing of the servers is 20% of the total, which would require an extension of the useful life to 11-18 years. </p> | |||
<h3>The total emissions cost from computing</h3> | |||
<p>Taking into account the carbon cost of both operation and production, computing would be responsible for 10 GtCO₂e by 2040, almost half of the acceptable CO₂ emissions budget <a href="#2">[2,3,14]</a>.</p> | |||
<figure> | |||
<img src="https://wimvanderbauwhede.github.io/images/computing-emissions.png" alt="A graph with two bars: world emissions (55) and emissions from computing (0.1) in 2020; and for 2040, the world emissions target to limit warming to 1.5°C (23), and the projected emissions from computing (10)" title="A graph with two bars: world emissions (55) and emissions from computing (0.1) in 2020; and for 2040, the world emissions target to limit warming to 1.5°C (23), and the projected emissions from computing (10)"> | |||
<figcaption>Actual and projected emissions from computing (production+operation), and 2040 emission target to limit warming to <2°C</figcaption> | |||
</figure> | |||
<h3>A breakdown per device type</h3> | |||
<p>To decide on the required actions to reduce emissions, it is important to look at the numbers of different types of devices and their energy usage. If we consider mobile phones as one category, laptops and desktops as another and servers as a third category, the questions are: how many devices are there in each category, and what is their energy consumption. The absolute numbers of devices in use are quite difficult to estimate, but the yearly sales figures <a href="#10">[10]</a> and estimates for the energy consumption for each category <a href="#11">[11,12,13,14]</a> are readily available from various sources. The tables below show the 2020 sales and yearly energy consumption estimates for each category of devices. A detailed analysis is presented in <a href="#14">[14]</a>.</p> | |||
<table> | |||
<caption>Number of devices sold worldwide in 2020</caption> | |||
<tr><th>Device type</th><th>2020 sales</th></tr> | |||
<tr><td>Phones</td><td> 3000M</td></tr> | |||
<tr><td>Servers</td><td> 13M</td></tr> | |||
<tr><td>Tablets</td><td> 160M</td></tr> | |||
<tr><td>Displays</td><td> 40M</td></tr> | |||
<tr><td>Laptops</td><td> 280M</td></tr> | |||
<tr><td>Desktops</td><td> 80M</td></tr> | |||
<tr><td>TVs</td><td>220M</td></tr> | |||
<tr><td>IoT devices</td><td> 2000M</td></tr> | |||
</table> | |||
<p>The energy consumption of all communication and computation technology currently in use in the world is currently around 3,000 TWh, about 11% of the world's electricity consumption, projected to rise by 3-4 times by 2040 with business as usual according to <a href="#2">[2]</a>. This is a conservative estimate: the study in <a href="#14">[14]</a> includes a worst-case projection of a rise to 30,000 TWh (exceeding the current world electricity consumption) by 2030. </p> | |||
<table> | |||
<caption>Yearly energy consumption estimates in TWh</caption> | |||
<tr><th>Device type</th><th>TWh</th></tr> | |||
<tr><td>TVs</td><td> 560</td></tr> | |||
<tr><td>Other Consumer devices</td><td> 240</td></tr> | |||
<tr><td>Fixed access network (wired+WiFi)</td><td> 900 + 500</td></tr> | |||
<tr><td>Mobile network</td><td> 100</td></tr> | |||
<tr><td>Data centres</td><td> 700</td></tr> | |||
<tr><td>Total</td><td> 3000</td></tr> | |||
</table> | |||
<p>The above data make it clear which actions are necessary: the main carbon cost of phones, tablets and IoT devices is their production and the use of the mobile network, so we must extend their useful life very considerably and reduce network utilisation. Extending the life time is also the key action for datacentres and desktop computers, but their energy consumption also needs to be reduced considerably, as does the energy consumption of the wired, WiFi and mobile networks. </p> | |||
<h2>A vision for low carbon and sustainable computing</h2> | |||
<p>It is clear that urgent action is needed: in less than two decades, the global use of computational resources needs to be transformed radically. Otherwise, the world will fail to meet its climate targets, even with significant reductions in other emission areas. The carbon cost of both production and operation of the devices must be considerably reduced. </p> | |||
<p>To use devices for longer, a change in business models as well as consumer attitudes is needed. This requires raising awareness and education but also providing incentives for behavioural change. And to support devices for a long time, an infrastructure for repair and maintenance is needed, with long-term availability of parts, open repair manuals and training. To make all this happen, economic incentives and policies will be needed (e.g. taxation, regulation). Therefore we need to convince key decision makers in society, politics and business.</p> | |||
<p>Imagine that we can extend the useful life of our devices and even increase their capabilities, purely through better computing science. With every improvement, the computational capacity will in effect increase without any increase in energy consumption. Meanwhile, we will develop the technologies for the next generation of devices, designed for energy efficiency as well as long life. Every subsequent cycle will last longer, until finally the world will have computing resources that last forever and hardly use any energy.</p> | |||
<figure> | |||
<img src="https://wimvanderbauwhede.github.io/images/towards-zero-carbon-computing.png" alt="A graph with four trends: emissions from production, emissions in total, performance and emissions/performance." title="A graph with four trends: emissions from production, emissions in total, performance and emissions/performance."> | |||
<figcaption>Towards zero carbon computing: increasing performance and lifetime and reducing emissions. Illustration with following assumptions: every new generation lasts twice as long as the previous one and cost half as much energy to produce; energy efficiency improves linearly with 5% per year.</figcaption> | |||
</figure> | |||
<p>This is a very challenging vision, spanning all aspects of computing science. To name just a few challenges:</p> | |||
<ul> | |||
<li>We must design software so that it supports devices with extended lifetimes.</li> | |||
<li>We need software engineering strategies to handle the extended software life cycles, and in particular deal with <a href="https://en.wikipedia.org/wiki/Technical_debt">technical debt</a>.</li> | |||
<li>Longer life means more opportunities to exploit vulnerabilities, so we need better cyber security.</li> | |||
<li>We need to develop new approaches to reduce overall energy consumption across the entire system.</li> | |||
</ul> | |||
<p>To address these challenges, action is needed on many fronts. What will you do to make frugal computing a reality?</p> | |||
<h2>References</h2> | |||
<p><small> | |||
<span id="1">[1] <a href="https://www.semiconductors.org/resources/rebooting-the-it-revolution-a-call-to-action-2/"><em>"Rebooting the IT revolution: a call to action"</em>, Semiconductor Industry Association/Semiconductor Research Corporation, Sept 2015</a></span><br> | |||
<span id="2">[2] <a href="https://www.src.org/about/decadal-plan/decadal-plan-full-report.pdf"><em>"Full Report for the Decadal Plan for Semiconductors"</em>, Semiconductor Industry Association/Semiconductor Research Corporation, Jan 2021</a></span><br> | |||
<span id="3">[3] <a href="https://www.sciencedirect.com/science/article/pii/S095965261733233X"><em>"Assessing ICT global emissions footprint: Trends to 2040 & recommendations"</em>, Lotfi Belkhir, Ahmed Elmeligi, Journal of Cleaner Production 177 (2018) 448--463</a></span><br> | |||
<span id="4">[4] <a href="https://www.epa.gov/ghgemissions/sources-greenhouse-gas-emissions"><em>"Sources of Greenhouse Gas Emissions"</em>, United States Environmental Protection Agency</a>, Last updated on April 14, 2021</span><br> | |||
<span id="5">[5] <a href="https://www.unep.org/emissions-gap-report-2020"><em>"Emissions Gap Report 2020"</em>, UN Environment Programme, December 2020</a></span><br> | |||
<span id="6">[6] <a href="https://onlinelibrary.wiley.com/doi/full/10.1111/jiec.13123"><em>"The link between product service lifetime and GHG emissions: A comparative study for different consumer products"</em>, Simon Glöser-Chahoud, Matthias Pfaff, Frank Schultmann, Journal of Industrial Ecology, 25 (2), pp 465-478, March 2021</a></span><br> | |||
<span id="7">[7] <a href="https://eeb.org/library/coolproducts-report/"><em>"Cool products don’t cost the Earth – Report"</em>, European Environmental Bureau, September 2019</a></span><br> | |||
<span id="8">[8] <a href="https://link.springer.com/article/10.1007/s11367-014-0838-7"><em>"The life cycle assessment of a UK data centre"</em>, Beth Whitehead, Deborah Andrews, Amip Shah, Graeme Maidment, Building and Environment 93 (2015) 395--405, January 2015</a></span><br> | |||
<span id="9">[9] <a href="https://www.statista.com">Statista</a>, retrieved June 2021</span><br> | |||
<span id="10">[10] <a href="https://www.iea.org/reports/global-energy-CO%E2%82%82-status-report-2019/emissions"><em>"Global Energy & CO₂ Status Report"</em>, International Energy Agency, March 2019</a></span><br> | |||
<span id="11">[11] <a href="https://link.springer.com/article/10.1007/s11367-015-0909-4"><em>"Redefining scope: the true environmental impact of smartphones?"</em>, James Suckling, Jacquetta Lee, The International Journal of Life Cycle Assessment volume 20, pages 1181–1196 (2015)</a></span><br> | |||
<span id="12">[12] <a href="https://www.racksolutions.com/news/blog/server-rack-power-consumption-calculator/"><em>"Server Rack Power Consumption Calculator"</em>, Rack Solutions, Inc., July 2019</a></span><br> | |||
<span id="13">[13] <a href="https://www.sciencedirect.com/science/article/pii/S111001682030524X"><em>"Analysis of energy consumption and potential energy savings of an institutional building in Malaysia"</em>, Siti Birkha Mohd Ali, M.Hasanuzzaman, N.A.Rahim, M.A.A.Mamun, U.H.Obaidellah, Alexandria Engineering Journal, Volume 60, Issue 1, February 2021, Pages 805-820</a></span><br> | |||
<span id="14">[14] <a href="https://doi.org/10.3390/challe6010117"><em>"On Global Electricity Usage of Communication Technology: Trends to 2030"</em>, Anders S. G. Andrae, Tomas Edler, Challenges 2015, 6(1), 117-157 </a></span><br> | |||
<span id="15">[15] <a href="https://www.bp.com/en/global/corporate/energy-economics/energy-outlook.html"><em>"BP Energy Outlook: 2020 Edition"</em>,BP plc</a></span><br> | |||
<span id="16">[16] <a href="https://www.semiconductors.org/resources/2015-international-technology-roadmap-for-semiconductors-itrs/"><em>"2015 International Technology Roadmap for Semiconductors (ITRS)"</em>, Semiconductor Industry Association, June 2015</a></span><br> | |||
</small></p> |
@@ -0,0 +1,206 @@ | |||
<!doctype html><!-- This is a valid HTML5 document. --> | |||
<!-- Screen readers, SEO, extensions and so on. --> | |||
<html lang="fr"> | |||
<!-- Has to be within the first 1024 bytes, hence before the `title` element | |||
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
<meta charset="utf-8"> | |||
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
<!-- The viewport meta is quite crowded and we are responsible for that. | |||
See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
<meta name="viewport" content="width=device-width,initial-scale=1"> | |||
<!-- Required to make a valid HTML5 document. --> | |||
<title>The First Question To Ask When Building Teams - Is This Really A Team? (archive) — David Larlet</title> | |||
<meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
<!-- That good ol' feed, subscribe :). --> | |||
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
<!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
<link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
<meta name="msapplication-TileColor" content="#f7f7f7"> | |||
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)"> | |||
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)"> | |||
<!-- Documented, feel free to shoot an email. --> | |||
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css"> | |||
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
<script> | |||
function toggleTheme(themeName) { | |||
document.documentElement.classList.toggle( | |||
'forced-dark', | |||
themeName === 'dark' | |||
) | |||
document.documentElement.classList.toggle( | |||
'forced-light', | |||
themeName === 'light' | |||
) | |||
} | |||
const selectedTheme = localStorage.getItem('theme') | |||
if (selectedTheme !== 'undefined') { | |||
toggleTheme(selectedTheme) | |||
} | |||
</script> | |||
<meta name="robots" content="noindex, nofollow"> | |||
<meta content="origin-when-cross-origin" name="referrer"> | |||
<!-- Canonical URL for SEO purposes --> | |||
<link rel="canonical" href="https://www.viktorcessan.com/the-first-question-to-ask-when-building-teams-is-this-really-a-team/"> | |||
<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all"> | |||
<article> | |||
<header> | |||
<h1>The First Question To Ask When Building Teams - Is This Really A Team?</h1> | |||
</header> | |||
<nav> | |||
<p class="center"> | |||
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use> | |||
</svg> Accueil</a> • | |||
<a href="https://www.viktorcessan.com/the-first-question-to-ask-when-building-teams-is-this-really-a-team/" title="Lien vers le contenu original">Source originale</a> | |||
</p> | |||
</nav> | |||
<hr> | |||
<p><span>Have you ever wondered why so many organizations fail at building effective and high performing teams despite offering so much support in different ways e.g. by managing people, by managing the environment, and by coaching teams? You’re not alone. This is often something that frustrates teams, coaches, and managers.</span></p> | |||
<p><span>You’d think that given all the support that teams receive, they would have great chances for becoming high performing. What our experience shows us, and </span><a href="https://www.adlibris.com/se/bok/creating-effective-teams-a-guide-for-members-and-leaders-9781483346120"><span>research</span></a><span>, is that it’s more uncommon than common for teams to get to a high performing state. While there are many reasons to why this happens, in this article we’re going to look at one often overlooked aspect of coaching teams. That is, whether the team, in fact, is a team or not. </span></p> | |||
<h2><b>Teams, Pseudo-Teams, Temporary Alliances, and Co-workers</b></h2> | |||
<p><span>You might assume that if you put together a bunch of people and give them a goal, they’re a team. But that’s not how it works. While all constellations are working groups of some sort, in order for a working group to be considered a team two criteria need to be met.</span></p> | |||
<p><span>First they need to have a common/shared goal and second, they need to truly need each other to reach that goal. The need can be objective, e.g. that someone has accesses or a necessary skill-set I lack, or the need can be subjective, e.g. I’ve come to prefer a collaborative way of working such as pair or mob programming. But only when these two criteria are met, a working group can be considered a team.</span></p> | |||
<p> </p> | |||
<p><img class="aligncenter wp-image-1951" src="https://www.viktorcessan.com/wp-content/uploads/2018/10/team-e1539010042693.png" srcset="https://www.viktorcessan.com/wp-content/uploads/2018/10/team-e1539010042693.png 696w, https://www.viktorcessan.com/wp-content/uploads/2018/10/team-e1539010042693-300x225.png 300w, https://www.viktorcessan.com/wp-content/uploads/2018/10/team-e1539010042693-20x15.png 20w, https://www.viktorcessan.com/wp-content/uploads/2018/10/team-e1539010042693-600x451.png 600w" data-sizes="(max-width: 500px) 100vw, 500px" data-swift-image-lazyload="true" data-style="" data-l></p> | |||
<h2><b>Pseudo-teams</b></h2> | |||
<p><span>Teams where the members do not necessarily need each other to reach their goal, despite the goal being shared, are merely Pseudo-Teams. In Pseudo-teams members often, but not always, report to a manager who assigns goals to the members individually or they do it in pairs. Sales teams, Customer Service Teams, Component teams, Channel teams (e.g. iOS, Android) are some examples where members from an objective standpoint </span><i><span>often</span></i><span> can accomplish their work and reach their goal without needing the help of other people in the working group.</span></p> | |||
<p><img class="aligncenter wp-image-1952" src="https://www.viktorcessan.com/wp-content/uploads/2018/10/pseudo-e1539010095120.png" srcset="https://www.viktorcessan.com/wp-content/uploads/2018/10/pseudo-e1539010095120.png 693w, https://www.viktorcessan.com/wp-content/uploads/2018/10/pseudo-e1539010095120-300x224.png 300w, https://www.viktorcessan.com/wp-content/uploads/2018/10/pseudo-e1539010095120-20x15.png 20w, https://www.viktorcessan.com/wp-content/uploads/2018/10/pseudo-e1539010095120-600x448.png 600w" data-sizes="(max-width: 500px) 100vw, 500px" data-swift-image-lazyload="true" data-style="" data-l></p> | |||
<h2><b>Temporary Alliances</b></h2> | |||
<p><span>When co-workers need each other for something specific but they don’t share a common goal they form Temporary Alliances. Examples of this are team members that embed perhaps to help a team adopt a new technology. Alternatively, if I need to get help from IT-support, or a new entry card to the building and I ask office management for help, I have formed Temporary Alliances. Knowledge sharing guilds are also examples of Temporary Alliances. A Temporary Alliance can last anywhere from minutes to months.</span></p> | |||
<p><img class="aligncenter wp-image-1953" src="https://www.viktorcessan.com/wp-content/uploads/2018/10/alliance-e1539010159514.png" srcset="https://www.viktorcessan.com/wp-content/uploads/2018/10/alliance-e1539010159514.png 667w, https://www.viktorcessan.com/wp-content/uploads/2018/10/alliance-e1539010159514-300x231.png 300w, https://www.viktorcessan.com/wp-content/uploads/2018/10/alliance-e1539010159514-20x15.png 20w, https://www.viktorcessan.com/wp-content/uploads/2018/10/alliance-e1539010159514-600x461.png 600w" data-sizes="(max-width: 500px) 100vw, 500px" data-swift-image-lazyload="true" data-style="" data-l></p> | |||
<h2><b>Co-Workers</b></h2> | |||
<p><span>When team members don’t share their daily goals and they don’t need each other to achieve them, they’re just co-workers. </span></p> | |||
<p><img class="aligncenter wp-image-1954" src="https://www.viktorcessan.com/wp-content/uploads/2018/10/co-workers-e1539010194306.png" srcset="https://www.viktorcessan.com/wp-content/uploads/2018/10/co-workers-e1539010194306.png 672w, https://www.viktorcessan.com/wp-content/uploads/2018/10/co-workers-e1539010194306-300x237.png 300w, https://www.viktorcessan.com/wp-content/uploads/2018/10/co-workers-e1539010194306-20x16.png 20w, https://www.viktorcessan.com/wp-content/uploads/2018/10/co-workers-e1539010194306-600x473.png 600w" data-sizes="(max-width: 500px) 100vw, 500px" data-swift-image-lazyload="true" data-style="" data-l></p> | |||
<h2><b>A common goal is both objective and subjective</b></h2> | |||
<p><span>While the need for each other can be either subjective or objective, having a common goal needs to be both subjective and objective. If a common goal is shared by the people in the team but the rest of the company doesn’t believe that’s the right goal, those forces will work to disband the team. </span></p> | |||
<p><span>If the company has a shared view of what the goal should be but only a few in the team share that view, subgroups will form. And of course most work can be linked towards the company’s overarching vision but that’s not what we’re talking about. We’re talking about goals as in daily work, monthly goals, quarterly goals, a year or years-long specific missions.</span></p> | |||
<p><span>So whatever the goal for the working group is, it has to be both objectively and subjectively shared.</span></p> | |||
<p><img class="aligncenter wp-image-1955" src="https://www.viktorcessan.com/wp-content/uploads/2018/10/need-and-goal-e1539010249636.png" srcset="https://www.viktorcessan.com/wp-content/uploads/2018/10/need-and-goal-e1539010249636.png 717w, https://www.viktorcessan.com/wp-content/uploads/2018/10/need-and-goal-e1539010249636-300x219.png 300w, https://www.viktorcessan.com/wp-content/uploads/2018/10/need-and-goal-e1539010249636-20x15.png 20w, https://www.viktorcessan.com/wp-content/uploads/2018/10/need-and-goal-e1539010249636-600x438.png 600w" data-sizes="(max-width: 500px) 100vw, 500px" data-swift-image-lazyload="true" data-style="" data-l></p> | |||
<h2><b>Knowing your type of working group</b></h2> | |||
<p><span>It’s crucial to pay attention to whether or not a working group is a team because it dictates what kind of structures to build and how to support the team. We see organizations spend tremendous amounts of energy in trying to coach Temporary Alliances and Pseudo-Teams as if they were teams, when in fact the kind of support those working groups needs is very different from what a team needs.</span></p> | |||
<p><span>Not only is this a wasted effort it’s also highly demotivating for the members to engage in activities that attempt to foster collaboration when it’s not necessary. Examples of this are daily stand-ups with people who don’t have any real reason to sync other than to possibly keep their manager updated (it’s really common still) – ever heard standups like this: </span><i><span>“Yesterday I went to these meetings, today I may think about this and attend these workshops, and I don’t have any impediments”</span></i><span> or </span><i><span>“What are you going to do today”</span></i><span>? </span></p> | |||
<p><span>Frequent offsites with Temporary Alliances aimed at team building with extensive getting to know each other exercises or talking about roles and responsibilities are also examples of misdirected efforts.</span></p> | |||
<h2><b>Only teams need to stick through the rough times</b></h2> | |||
<p><span>Different working groups are affected by group dynamics in different ways. A team has to get through the rough times because they do need each other. A Temporary Alliance will often never work together long enough to get to the storming phase (see </span><a href="https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development"><span>Tuckman’s stages of group development</span></a><span>)or they may change or disband the alliance because they don’t really share a common goal and they don’t need to stick through difficult times. They can fake it until they don’t need to.</span></p> | |||
<p><span>The same goes for a Pseudo-team. When the times get tough, the team members can either try to work their way through the difficult times or they can just stop showing up to meetings, work from home, etc. They simply don’t actually need each other.</span></p> | |||
<h2><b>Running a retro about what type of working group you have</b></h2> | |||
<p><span>If you haven’t thought about this before, if you’re generally curious, or if your team isn’t collaborating to the extent you were hoping, ask yourself what kind of working group they are. Or better yet, facilitate a conversation with the team / run a retro about what type of working group you are. Here’s a simple format you can use with your team:</span></p> | |||
<ol> <li><span>Set the stage and mention that this retro is about determining whether or not we’re a team, and if we’re collaborating enough according to our own views.</span></li> <li><span>Draw the working group framework without naming the quadrants and ask the working group to plot how much they individually need the other members of the team to achieve their goal, and how much they perceive their goal to be shared by the other members. </span></li> <li><span>Once people have answered write out the names of the quadrants. As little as one member not being in the team-quadrant is enough to negatively affect the team dynamics and hinder the group from ever reaching a performing state.</span></li> <li><span>Now ask the working group whether or not they want to be a team, and whether or not they want to collaborate (and how much and in what types of questions). </span></li> <li><span>It may be helpful to have the roadmap and vision available when the team starts discussing point 3 if they start discussing if they have a common goal or not.</span></li> <li><span>If the team wants to collaborate more / and want to work more towards a common goal, have them generate actions on what they think would lead to that.</span></li> </ol> | |||
</article> | |||
<hr> | |||
<footer> | |||
<p> | |||
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use> | |||
</svg> Accueil</a> • | |||
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-rss2"></use> | |||
</svg> Suivre</a> • | |||
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-user-tie"></use> | |||
</svg> Pro</a> • | |||
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-mail"></use> | |||
</svg> Email</a> • | |||
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-hammer2"></use> | |||
</svg> Légal</abbr> | |||
</p> | |||
<template id="theme-selector"> | |||
<form> | |||
<fieldset> | |||
<legend><svg class="icon icon-brightness-contrast"> | |||
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-brightness-contrast"></use> | |||
</svg> Thème</legend> | |||
<label> | |||
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
</label> | |||
<label> | |||
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
</label> | |||
<label> | |||
<input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
</label> | |||
</fieldset> | |||
</form> | |||
</template> | |||
</footer> | |||
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script> | |||
<script> | |||
function loadThemeForm(templateName) { | |||
const themeSelectorTemplate = document.querySelector(templateName) | |||
const form = themeSelectorTemplate.content.firstElementChild | |||
themeSelectorTemplate.replaceWith(form) | |||
form.addEventListener('change', (e) => { | |||
const chosenColorScheme = e.target.value | |||
localStorage.setItem('theme', chosenColorScheme) | |||
toggleTheme(chosenColorScheme) | |||
}) | |||
const selectedTheme = localStorage.getItem('theme') | |||
if (selectedTheme && selectedTheme !== 'undefined') { | |||
form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
} | |||
} | |||
const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
window.addEventListener('load', () => { | |||
let hasDarkRules = false | |||
for (const styleSheet of Array.from(document.styleSheets)) { | |||
let mediaRules = [] | |||
for (const cssRule of styleSheet.cssRules) { | |||
if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
continue | |||
} | |||
// WARNING: Safari does not have/supports `conditionText`. | |||
if (cssRule.conditionText) { | |||
if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
continue | |||
} | |||
} else { | |||
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
continue | |||
} | |||
} | |||
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
} | |||
// WARNING: do not try to insert a Rule to a styleSheet you are | |||
// currently iterating on, otherwise the browser will be stuck | |||
// in a infinite loop… | |||
for (const mediaRule of mediaRules) { | |||
styleSheet.insertRule(mediaRule.cssText) | |||
hasDarkRules = true | |||
} | |||
} | |||
if (hasDarkRules) { | |||
loadThemeForm('#theme-selector') | |||
} | |||
}) | |||
</script> | |||
</body> | |||
</html> |
@@ -0,0 +1,17 @@ | |||
title: The First Question To Ask When Building Teams - Is This Really A Team? | |||
url: https://www.viktorcessan.com/the-first-question-to-ask-when-building-teams-is-this-really-a-team/ | |||
hash_url: 77419ba77876ddc880823ee6321f9cbe | |||
<p><span>Have you ever wondered why so many organizations fail at building effective and high performing teams despite offering so much support in different ways e.g. by managing people, by managing the environment, and by coaching teams? You’re not alone. This is often something that frustrates teams, coaches, and managers.</span></p> <p><span>You’d think that given all the support that teams receive, they would have great chances for becoming high performing. What our experience shows us, and </span><a href="https://www.adlibris.com/se/bok/creating-effective-teams-a-guide-for-members-and-leaders-9781483346120"><span>research</span></a><span>, is that it’s more uncommon than common for teams to get to a high performing state. While there are many reasons to why this happens, in this article we’re going to look at one often overlooked aspect of coaching teams. That is, whether the team, in fact, is a team or not. </span></p> | |||
<h2><b>Teams, Pseudo-Teams, Temporary Alliances, and Co-workers</b></h2> <p><span>You might assume that if you put together a bunch of people and give them a goal, they’re a team. But that’s not how it works. While all constellations are working groups of some sort, in order for a working group to be considered a team two criteria need to be met.</span></p> <p><span>First they need to have a common/shared goal and second, they need to truly need each other to reach that goal. The need can be objective, e.g. that someone has accesses or a necessary skill-set I lack, or the need can be subjective, e.g. I’ve come to prefer a collaborative way of working such as pair or mob programming. But only when these two criteria are met, a working group can be considered a team.</span></p> <p> </p> <p><img class="aligncenter wp-image-1951" src="https://www.viktorcessan.com/wp-content/uploads/2018/10/team-e1539010042693.png" srcset="https://www.viktorcessan.com/wp-content/uploads/2018/10/team-e1539010042693.png 696w, https://www.viktorcessan.com/wp-content/uploads/2018/10/team-e1539010042693-300x225.png 300w, https://www.viktorcessan.com/wp-content/uploads/2018/10/team-e1539010042693-20x15.png 20w, https://www.viktorcessan.com/wp-content/uploads/2018/10/team-e1539010042693-600x451.png 600w" data-sizes="(max-width: 500px) 100vw, 500px" data-swift-image-lazyload="true" data-style="" data-l></p> | |||
<h2><b>Pseudo-teams</b></h2> <p><span>Teams where the members do not necessarily need each other to reach their goal, despite the goal being shared, are merely Pseudo-Teams. In Pseudo-teams members often, but not always, report to a manager who assigns goals to the members individually or they do it in pairs. Sales teams, Customer Service Teams, Component teams, Channel teams (e.g. iOS, Android) are some examples where members from an objective standpoint </span><i><span>often</span></i><span> can accomplish their work and reach their goal without needing the help of other people in the working group.</span></p> <p><img class="aligncenter wp-image-1952" src="https://www.viktorcessan.com/wp-content/uploads/2018/10/pseudo-e1539010095120.png" srcset="https://www.viktorcessan.com/wp-content/uploads/2018/10/pseudo-e1539010095120.png 693w, https://www.viktorcessan.com/wp-content/uploads/2018/10/pseudo-e1539010095120-300x224.png 300w, https://www.viktorcessan.com/wp-content/uploads/2018/10/pseudo-e1539010095120-20x15.png 20w, https://www.viktorcessan.com/wp-content/uploads/2018/10/pseudo-e1539010095120-600x448.png 600w" data-sizes="(max-width: 500px) 100vw, 500px" data-swift-image-lazyload="true" data-style="" data-l></p> | |||
<h2><b>Temporary Alliances</b></h2> <p><span>When co-workers need each other for something specific but they don’t share a common goal they form Temporary Alliances. Examples of this are team members that embed perhaps to help a team adopt a new technology. Alternatively, if I need to get help from IT-support, or a new entry card to the building and I ask office management for help, I have formed Temporary Alliances. Knowledge sharing guilds are also examples of Temporary Alliances. A Temporary Alliance can last anywhere from minutes to months.</span></p> <p><img class="aligncenter wp-image-1953" src="https://www.viktorcessan.com/wp-content/uploads/2018/10/alliance-e1539010159514.png" srcset="https://www.viktorcessan.com/wp-content/uploads/2018/10/alliance-e1539010159514.png 667w, https://www.viktorcessan.com/wp-content/uploads/2018/10/alliance-e1539010159514-300x231.png 300w, https://www.viktorcessan.com/wp-content/uploads/2018/10/alliance-e1539010159514-20x15.png 20w, https://www.viktorcessan.com/wp-content/uploads/2018/10/alliance-e1539010159514-600x461.png 600w" data-sizes="(max-width: 500px) 100vw, 500px" data-swift-image-lazyload="true" data-style="" data-l></p> | |||
<h2><b>Co-Workers</b></h2> <p><span>When team members don’t share their daily goals and they don’t need each other to achieve them, they’re just co-workers. </span></p> <p><img class="aligncenter wp-image-1954" src="https://www.viktorcessan.com/wp-content/uploads/2018/10/co-workers-e1539010194306.png" srcset="https://www.viktorcessan.com/wp-content/uploads/2018/10/co-workers-e1539010194306.png 672w, https://www.viktorcessan.com/wp-content/uploads/2018/10/co-workers-e1539010194306-300x237.png 300w, https://www.viktorcessan.com/wp-content/uploads/2018/10/co-workers-e1539010194306-20x16.png 20w, https://www.viktorcessan.com/wp-content/uploads/2018/10/co-workers-e1539010194306-600x473.png 600w" data-sizes="(max-width: 500px) 100vw, 500px" data-swift-image-lazyload="true" data-style="" data-l></p> | |||
<h2><b>A common goal is both objective and subjective</b></h2> <p><span>While the need for each other can be either subjective or objective, having a common goal needs to be both subjective and objective. If a common goal is shared by the people in the team but the rest of the company doesn’t believe that’s the right goal, those forces will work to disband the team. </span></p> <p><span>If the company has a shared view of what the goal should be but only a few in the team share that view, subgroups will form. And of course most work can be linked towards the company’s overarching vision but that’s not what we’re talking about. We’re talking about goals as in daily work, monthly goals, quarterly goals, a year or years-long specific missions.</span></p> <p><span>So whatever the goal for the working group is, it has to be both objectively and subjectively shared.</span></p> <p><img class="aligncenter wp-image-1955" src="https://www.viktorcessan.com/wp-content/uploads/2018/10/need-and-goal-e1539010249636.png" srcset="https://www.viktorcessan.com/wp-content/uploads/2018/10/need-and-goal-e1539010249636.png 717w, https://www.viktorcessan.com/wp-content/uploads/2018/10/need-and-goal-e1539010249636-300x219.png 300w, https://www.viktorcessan.com/wp-content/uploads/2018/10/need-and-goal-e1539010249636-20x15.png 20w, https://www.viktorcessan.com/wp-content/uploads/2018/10/need-and-goal-e1539010249636-600x438.png 600w" data-sizes="(max-width: 500px) 100vw, 500px" data-swift-image-lazyload="true" data-style="" data-l></p> | |||
<h2><b>Knowing your type of working group</b></h2> <p><span>It’s crucial to pay attention to whether or not a working group is a team because it dictates what kind of structures to build and how to support the team. We see organizations spend tremendous amounts of energy in trying to coach Temporary Alliances and Pseudo-Teams as if they were teams, when in fact the kind of support those working groups needs is very different from what a team needs.</span></p> <p><span>Not only is this a wasted effort it’s also highly demotivating for the members to engage in activities that attempt to foster collaboration when it’s not necessary. Examples of this are daily stand-ups with people who don’t have any real reason to sync other than to possibly keep their manager updated (it’s really common still) – ever heard standups like this: </span><i><span>“Yesterday I went to these meetings, today I may think about this and attend these workshops, and I don’t have any impediments”</span></i><span> or </span><i><span>“What are you going to do today”</span></i><span>? </span></p> <p><span>Frequent offsites with Temporary Alliances aimed at team building with extensive getting to know each other exercises or talking about roles and responsibilities are also examples of misdirected efforts.</span></p> | |||
<h2><b>Only teams need to stick through the rough times</b></h2> <p><span>Different working groups are affected by group dynamics in different ways. A team has to get through the rough times because they do need each other. A Temporary Alliance will often never work together long enough to get to the storming phase (see </span><a href="https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development"><span>Tuckman’s stages of group development</span></a><span>)or they may change or disband the alliance because they don’t really share a common goal and they don’t need to stick through difficult times. They can fake it until they don’t need to.</span></p> <p><span>The same goes for a Pseudo-team. When the times get tough, the team members can either try to work their way through the difficult times or they can just stop showing up to meetings, work from home, etc. They simply don’t actually need each other.</span></p> | |||
<h2><b>Running a retro about what type of working group you have</b></h2> <p><span>If you haven’t thought about this before, if you’re generally curious, or if your team isn’t collaborating to the extent you were hoping, ask yourself what kind of working group they are. Or better yet, facilitate a conversation with the team / run a retro about what type of working group you are. Here’s a simple format you can use with your team:</span></p> <ol> <li><span>Set the stage and mention that this retro is about determining whether or not we’re a team, and if we’re collaborating enough according to our own views.</span></li> <li><span>Draw the working group framework without naming the quadrants and ask the working group to plot how much they individually need the other members of the team to achieve their goal, and how much they perceive their goal to be shared by the other members. </span></li> <li><span>Once people have answered write out the names of the quadrants. As little as one member not being in the team-quadrant is enough to negatively affect the team dynamics and hinder the group from ever reaching a performing state.</span></li> <li><span>Now ask the working group whether or not they want to be a team, and whether or not they want to collaborate (and how much and in what types of questions). </span></li> <li><span>It may be helpful to have the roadmap and vision available when the team starts discussing point 3 if they start discussing if they have a common goal or not.</span></li> <li><span>If the team wants to collaborate more / and want to work more towards a common goal, have them generate actions on what they think would lead to that.</span></li> </ol> |
@@ -107,6 +107,8 @@ | |||
<li><a href="/david/cache/2021/413c4ae36b9d7f577768dcc991561268/" title="Accès à l’article dans le cache local : 🚨 How Basecamp blew up">🚨 How Basecamp blew up</a> (<a href="https://www.platformer.news/p/-how-basecamp-blew-up" title="Accès à l’article original distant : 🚨 How Basecamp blew up">original</a>)</li> | |||
<li><a href="/david/cache/2021/0f791a9509f762f1a1a36b6ca2333230/" title="Accès à l’article dans le cache local : Permacomputing Update 2021">Permacomputing Update 2021</a> (<a href="http://viznut.fi/texts-en/permacomputing_update_2021.html" title="Accès à l’article original distant : Permacomputing Update 2021">original</a>)</li> | |||
<li><a href="/david/cache/2021/cd910565715dbc18d4b31ad60546a4a3/" title="Accès à l’article dans le cache local : CommunityWiki: Smol Net">CommunityWiki: Smol Net</a> (<a href="https://communitywiki.org/wiki/SmolNet" title="Accès à l’article original distant : CommunityWiki: Smol Net">original</a>)</li> | |||
<li><a href="/david/cache/2021/e4773951c7ed25cbab530ce2c20bd18a/" title="Accès à l’article dans le cache local : Comprendre la défiance envers le vaccin pour sortir de l’épidémie de Covid">Comprendre la défiance envers le vaccin pour sortir de l’épidémie de Covid</a> (<a href="https://www.frustrationmagazine.fr/comprendre-la-defiance-envers-le-vaccin/" title="Accès à l’article original distant : Comprendre la défiance envers le vaccin pour sortir de l’épidémie de Covid">original</a>)</li> | |||
@@ -181,6 +183,8 @@ | |||
<li><a href="/david/cache/2021/d61a48db32e2449d702ec5e558afbfa4/" title="Accès à l’article dans le cache local : Journal de f6k, vol. 11 num. 102">Journal de f6k, vol. 11 num. 102</a> (<a href="http://shl.huld.re/~f6k/log/vol11/102-eau.html" title="Accès à l’article original distant : Journal de f6k, vol. 11 num. 102">original</a>)</li> | |||
<li><a href="/david/cache/2021/710f8cdebd7560223ebd378f9cbe7822/" title="Accès à l’article dans le cache local : Frugal computing">Frugal computing</a> (<a href="https://wimvanderbauwhede.github.io/articles/frugal-computing/" title="Accès à l’article original distant : Frugal computing">original</a>)</li> | |||
<li><a href="/david/cache/2021/c4dd46c6f0fe9310b47dd3abda0b5280/" title="Accès à l’article dans le cache local : The computer built to last 50 years">The computer built to last 50 years</a> (<a href="https://ploum.net/the-computer-built-to-last-50-years/" title="Accès à l’article original distant : The computer built to last 50 years">original</a>)</li> | |||
<li><a href="/david/cache/2021/cbd2101777421fa7549472859210a69c/" title="Accès à l’article dans le cache local : HTTPWTF">HTTPWTF</a> (<a href="https://httptoolkit.tech/blog/http-wtf/" title="Accès à l’article original distant : HTTPWTF">original</a>)</li> | |||
@@ -237,6 +241,8 @@ | |||
<li><a href="/david/cache/2021/40df5f72a34059f94a965454efb97b07/" title="Accès à l’article dans le cache local : Design Accessible, la genèse d’un projet">Design Accessible, la genèse d’un projet</a> (<a href="https://blog.hello-bokeh.fr/2021/05/31/design-accessible-la-genese-dun-projet/" title="Accès à l’article original distant : Design Accessible, la genèse d’un projet">original</a>)</li> | |||
<li><a href="/david/cache/2021/231eb74b73be464d2cd8fc8e3a128e55/" title="Accès à l’article dans le cache local : The Three Kinds of Organizational Power">The Three Kinds of Organizational Power</a> (<a href="https://jacobian.org/2021/mar/15/organizational-power/" title="Accès à l’article original distant : The Three Kinds of Organizational Power">original</a>)</li> | |||
<li><a href="/david/cache/2021/837e11a57aa3ddcba084963c247f45a6/" title="Accès à l’article dans le cache local : What Is Going To Happen In 2021">What Is Going To Happen In 2021</a> (<a href="https://avc.com/2021/01/what-is-going-to-happen-in-2021/" title="Accès à l’article original distant : What Is Going To Happen In 2021">original</a>)</li> | |||
<li><a href="/david/cache/2021/3a94b388ab64cd27e1eb261eeb70ca63/" title="Accès à l’article dans le cache local : Plus vite, plus haut … plus de vues.">Plus vite, plus haut … plus de vues.</a> (<a href="https://www.affordance.info/mon_weblog/2021/08/plus-vite-plus-haut-plus-de-vues.html" title="Accès à l’article original distant : Plus vite, plus haut … plus de vues.">original</a>)</li> | |||
@@ -323,6 +329,8 @@ | |||
<li><a href="/david/cache/2021/d3a653c926aa97707653300947b65ab5/" title="Accès à l’article dans le cache local : The Mobile Performance Inequality Gap, 2021">The Mobile Performance Inequality Gap, 2021</a> (<a href="https://infrequently.org/2021/03/the-performance-inequality-gap/" title="Accès à l’article original distant : The Mobile Performance Inequality Gap, 2021">original</a>)</li> | |||
<li><a href="/david/cache/2021/77419ba77876ddc880823ee6321f9cbe/" title="Accès à l’article dans le cache local : The First Question To Ask When Building Teams - Is This Really A Team?">The First Question To Ask When Building Teams - Is This Really A Team?</a> (<a href="https://www.viktorcessan.com/the-first-question-to-ask-when-building-teams-is-this-really-a-team/" title="Accès à l’article original distant : The First Question To Ask When Building Teams - Is This Really A Team?">original</a>)</li> | |||
<li><a href="/david/cache/2021/4a9c4c407b34c40ec5b3783ac5f274a7/" title="Accès à l’article dans le cache local : Three requests for the Google Chrome team as they experiment with RSS">Three requests for the Google Chrome team as they experiment with RSS</a> (<a href="https://interconnected.org/home/2021/05/26/chrome_and_rss" title="Accès à l’article original distant : Three requests for the Google Chrome team as they experiment with RSS">original</a>)</li> | |||
<li><a href="/david/cache/2021/78f2e167938eb4bfa6747503aefe45c1/" title="Accès à l’article dans le cache local : We Quit Our Jobs to Build a Cabin-Everything Went Wrong">We Quit Our Jobs to Build a Cabin-Everything Went Wrong</a> (<a href="https://www.outsideonline.com/2415766/friends-diy-cabin-build-washington" title="Accès à l’article original distant : We Quit Our Jobs to Build a Cabin-Everything Went Wrong">original</a>)</li> |