davidbgk
/
larlet-fr-david-cache
Watch 1
Star 0
Fork 0
Code Releases 0 Activity
Browse Source

Links

master
David Larlet 3 months ago
parent
7afb79b1fa
commit
e6bfeacebc
Signed by: David Larlet <david@larlet.fr> GPG Key ID: 3E2953A359E7E7BD
5 changed files with 445 additions and 0 deletions
Split View Show Diff Stats
  1. 187
    0
      cache/2024/7ed7f4aefae1b5af33b3ec1f607a633f/index.html
  2. 22
    0
      cache/2024/7ed7f4aefae1b5af33b3ec1f607a633f/index.md
  3. 201
    0
      cache/2024/82b88d48d8043d79425ce8afd8dff42e/index.html
  4. 31
    0
      cache/2024/82b88d48d8043d79425ce8afd8dff42e/index.md
  5. 4
    0
      cache/2024/index.html

+ 187
- 0
cache/2024/7ed7f4aefae1b5af33b3ec1f607a633f/index.html View File

@@ -0,0 +1,187 @@
<!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>L’Observatoire des perspectives utopiques (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)">
<!-- Is that even respected? Retrospectively? What a shAItshow…
https://neil-clarke.com/block-the-bots-that-feed-ai-models-by-scraping-your-website/ -->
<meta name="robots" content="noai, noimageai">
<!-- 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://lobsoco.com/perspectives-utopiques-vague-3/">

<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>L’Observatoire des perspectives utopiques</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-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://lobsoco.com/perspectives-utopiques-vague-3/" title="Lien vers le contenu original">Source originale</a>
<br>
Mis en cache le 2024-01-24
</p>
</nav>
<hr>
<h2>Explorer 3 modèles de société</h2>
<p>La première vague de l’Observatoire des perspectives utopiques a été réalisée en 2019. Notre désir d’explorer comment les Français se représentent une société idéale était né du sentiment que, le projet « moderne » ayant en quelque sorte rempli son contrat et révélant désormais surtout sa face sombre, les sociétés occidentales souffraient d’un manque d’idéaux, d’un déficit d’objectifs collectifs à atteindre, d’une panne du désir d’avenir.</p>
<p>Avec nos partenaires (l’ADEME, BPI France Le Lab et la Chaire ESCP – Bearing Point), nous avions donc élaboré une méthodologie d’enquête consistant à recueillir comment un échantillon représentatif de Français évaluaient trois « sociétés idéales » que nous avions élaborées à partir d’idées portées par des auteurs, des mouvements sociaux, des courants politiques… ainsi que leurs aspirations par rapport à différentes dimensions plus spécifiques de l’organisation de la société.</p>
<h2>Quel impact de la crise sanitaire sur les représentations de la société idéale ?</h2>
<p>Depuis, les Français, comme l’ensemble des habitants du monde, ont vécu un évènement inédit aux impacts majeurs : la crise sanitaire. La sidération qui nous a saisi face à la violence du choc, à la radicalité des mesures adoptées en réaction et au bouleversement des modes de vie qui l’a accompagné ont créé un contexte favorable à la réflexion sur le sens à donner à cet « évènement » et sur les conséquences qu’il convenait d’en déduire, tant sur l’organisation de la vie économique et sociale qu’à échelle individuelle des priorités à donner à l’existence. Les premiers mois de la crise sanitaire ont donné lieu à des débats prolifiques. Beaucoup se sont mis à penser (ou à espérer) que le « monde d’après » serait nécessairement différent du « monde d’avant ». Les enquêtes que nous menons à L’ObSoCo sur divers aspects des modes de vie et de consommation ont eu tendance à montrer que, hormis l’accélération de la numérisation des modes de vie et les effets de la diffusion du télétravail, le balancier du changement avait une forte tendance à revenir vers sa position initiale. Mais qu’en est-il des manières dont les Français se représentent une société idéale ?</p>
<p>L’expérience de la crise sanitaire a-t-elle conduit à des réaménagements des idéaux et des aspirations tels qu’ils étaient relevés en 2019 par l’Observatoire ? C’est notamment pour répondre à cette question que, avec l’Ademe et BPI France Le Lab, nous avons décidé de relancer l’enquête, à l’identique de celle de 2019*, deux ans et demi plus tard, « à froid », alors que la phase de sidération est désormais derrière nous, que la pandémie – toujours là – fait moins de ravages depuis la vaccination massive et que nous avons appris à « vivre avec ».</p>
<ul>
<li>Une deuxième vague de l’enquête, centrée sur l’évaluation des 3 modèles de société, a été conduite en juin 2020, à la sortie du premier confinement.</li>
</ul>
<h2>Méthodologie</h2>
<p>Le terrain de cet Observatoire des perspectives utopiques a été mené du 17 au 27 janvier 2022 auprès d’un échantillon de 4000 personnes représentatives de la population française âgée de 18 à 75 ans. Le terrain s’est donc tenu avant le début de la guerre en Ukraine.</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-2021-12.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-2021-12.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-2021-12.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-2021-12.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-2021-12.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-2021-12.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>

+ 22
- 0
cache/2024/7ed7f4aefae1b5af33b3ec1f607a633f/index.md View File

@@ -0,0 +1,22 @@
title: L’Observatoire des perspectives utopiques
url: https://lobsoco.com/perspectives-utopiques-vague-3/
hash_url: 7ed7f4aefae1b5af33b3ec1f607a633f
archive_date: 2024-01-24

## Explorer 3 modèles de société

La première vague de l’Observatoire des perspectives utopiques a été réalisée en 2019. Notre désir d’explorer comment les Français se représentent une société idéale était né du sentiment que, le projet « moderne » ayant en quelque sorte rempli son contrat et révélant désormais surtout sa face sombre, les sociétés occidentales souffraient d’un manque d’idéaux, d’un déficit d’objectifs collectifs à atteindre, d’une panne du désir d’avenir.

Avec nos partenaires (l’ADEME, BPI France Le Lab et la Chaire ESCP – Bearing Point), nous avions donc élaboré une méthodologie d’enquête consistant à recueillir comment un échantillon représentatif de Français évaluaient trois « sociétés idéales » que nous avions élaborées à partir d’idées portées par des auteurs, des mouvements sociaux, des courants politiques… ainsi que leurs aspirations par rapport à différentes dimensions plus spécifiques de l’organisation de la société.

## Quel impact de la crise sanitaire sur les représentations de la société idéale ?

Depuis, les Français, comme l’ensemble des habitants du monde, ont vécu un évènement inédit aux impacts majeurs : la crise sanitaire. La sidération qui nous a saisi face à la violence du choc, à la radicalité des mesures adoptées en réaction et au bouleversement des modes de vie qui l’a accompagné ont créé un contexte favorable à la réflexion sur le sens à donner à cet « évènement » et sur les conséquences qu’il convenait d’en déduire, tant sur l’organisation de la vie économique et sociale qu’à échelle individuelle des priorités à donner à l’existence. Les premiers mois de la crise sanitaire ont donné lieu à des débats prolifiques. Beaucoup se sont mis à penser (ou à espérer) que le « monde d’après » serait nécessairement différent du « monde d’avant ». Les enquêtes que nous menons à L’ObSoCo sur divers aspects des modes de vie et de consommation ont eu tendance à montrer que, hormis l’accélération de la numérisation des modes de vie et les effets de la diffusion du télétravail, le balancier du changement avait une forte tendance à revenir vers sa position initiale. Mais qu’en est-il des manières dont les Français se représentent une société idéale ?

L’expérience de la crise sanitaire a-t-elle conduit à des réaménagements des idéaux et des aspirations tels qu’ils étaient relevés en 2019 par l’Observatoire ? C’est notamment pour répondre à cette question que, avec l’Ademe et BPI France Le Lab, nous avons décidé de relancer l’enquête, à l’identique de celle de 2019*, deux ans et demi plus tard, « à froid », alors que la phase de sidération est désormais derrière nous, que la pandémie – toujours là – fait moins de ravages depuis la vaccination massive et que nous avons appris à « vivre avec ».

* Une deuxième vague de l’enquête, centrée sur l’évaluation des 3 modèles de société, a été conduite en juin 2020, à la sortie du premier confinement.

## Méthodologie

Le terrain de cet Observatoire des perspectives utopiques a été mené du 17 au 27 janvier 2022 auprès d’un échantillon de 4000 personnes représentatives de la population française âgée de 18 à 75 ans. Le terrain s’est donc tenu avant le début de la guerre en Ukraine.

+ 201
- 0
cache/2024/82b88d48d8043d79425ce8afd8dff42e/index.html View File

@@ -0,0 +1,201 @@
<!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>Echoing Wirth's plea for lean software (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)">
<!-- Is that even respected? Retrospectively? What a shAItshow…
https://neil-clarke.com/block-the-bots-that-feed-ai-models-by-scraping-your-website/ -->
<meta name="robots" content="noai, noimageai">
<!-- 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://blog.testdouble.com/posts/2024-01-24-plea-for-lean/">

<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>Echoing Wirth's plea for lean software</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-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://blog.testdouble.com/posts/2024-01-24-plea-for-lean/" title="Lien vers le contenu original">Source originale</a>
<br>
Mis en cache le 2024-01-24
</p>
</nav>
<hr>
<p>Our industry lost one of its great minds on New Year’s Day as Niklaus Wirth passed at the age of 89. My first real computer programming class in high school used Pascal, which he designed in 1970, and the majority of my college courses used Modula-2, which he also designed in 1975. Both of these languages advanced the field of programming with innovations like modules, one-pass compilation, and concurrent programming. The type safety, clarity, and compiler support made these languages very approachable and easy to learn, likely keeping me on the path of a career in our industry. One of his greatest contributions to our field, that seems eerily prescient now, is his article “A Plea for Lean Software” published in Computer magazine in 1995.</p>
<p>The article laments the fact that we have been conditioned with significant advances in hardware, leading to software that is unnecessarily bloated. Humorously, the article begins by addressing how memory requirements jump “from several to many megabytes." I am writing this blog post in a browser window that is consuming 700MB while reviewing his article in Preview, clocking in at just shy of 1GB of memory consumption, almost proving his point 29 years later.</p>
<p><strong>We are spoiled</strong></p>
<p>The premise that software projects and programmers have become spoiled by the rapid advances in hardware is evident now more than ever. I carry around an iPhone 15 that has 2.15 teraflops of processing power. The most powerful supercomputer at the time I graduated college in 1998 could only do 1.6 teraflops. Looking back 25 years, it’s hard to imagine software development on such antiquated hardware, but I can attest that many of the systems we developed in the late 90s and early 2000s are still running to this day. Many of the biggest businesses with systems that need minimal downtime and no margin of error still run mainframe systems that were built in the 80s and 90s. Contrast that to the build in 3 months, run for 3 years, and then rewrite it all pattern that is so prevalent in businesses today and I think Mr. Wirth may have been on to something.</p>
<p>His article focused almost completely on the advances in hardware that were spoiling us, but 30 years later we also have massive advances in software that provide significant gains in programming efficiency. We operate on programming languages and frameworks that no longer require us to manually manage memory consumption. There’s largely no need for configuring parallelism in our systems for computational heavy tasks. In almost any web development language, we can largely pull in a number of prebuilt frameworks or packages that will solve a huge number of problems that he would’ve had to tackle himself. How then was he so much more productive than most of the teams I see today?</p>
<p>In the article, he’s trying to distill the lessons they learned while creating the Oberon System, a text-based user interface and operating system that he and a colleague completed in 3 years. It was based upon the programming language Oberon, which they also developed in this time. Keep in mind, they designed and developed this system 37 years ago, when their workstations likely had less than 2MB of RAM and were able to perform maybe 2M instructions per second. I struggle to imagine even the best programmers that I know creating an OS and a programming language under these constraints. What led to their success?</p>
<p><strong>MOAR FEATURES</strong></p>
<p>A point that he makes consistently throughout the article is that, as an industry, we have tendency to build a lot of features that no one really wants or needs.</p>
<p><em>Uncontrolled software growth has also been accepted because customers have trouble distinguishing between essential features and those that are just “nice to have.”</em></p>
<p>We see this all. the. time. Software businesses that are bootstrapped or early stage have to focus maniacally on only building the features that are proven to be critical to adoption. Then as adoption picks up, a second or third round of funding comes in, and these same businesses accelerate right out of the lean startup mindset. That first sales hire brings every idea to the table that a prospect may have mentioned into the newer and longer list of <strong>critical features</strong>. Immature product management does a poor job of validating the features and pruning the list into the set of features that truly drive outcomes.</p>
<p>It results in large systems that are extremely difficult for end users to operate within. Simplicity is inversely proportional to the number of features available for use.</p>

<p><img src="https://cdn-blog.testdouble.com/img/plea-for-lean/simplicity-graph.f6526546c7913435ddea37cc72251c703d73bd6a7fc05e8b2bc7f3dc0fa98798.png" alt="Simplicity vs Features" class="" loading="eager"></p>
<p>When simplicity goes away, businesses are then forced to invest in other areas like documentation, training, and customer support. All for a user experience that is more likely to drive away new customers instead of achieving the original goal of bringing more users in. If you don’t believe me, ask yourself how often you see teams prioritize removing neglected features as part of their planning?</p>
<p><em>Any and all features mean design becomes more complicated and usability more cumbersome.</em></p>
<p>This incessant accumulation of features results in another cause for inefficiency: larger and larger software organizations.</p>
<p><strong>MOAR DEVELOPERS</strong></p>
<p>In my experience, overly complicated software designs are the number one reason for failure within software focused businesses. Yet engineering leaders rarely focus on addressing complexity within their systems. I can only assume that they believe the complexity is necessary and not incidental, which leaves them with only one option to pursue: throw more bodies at the problem.</p>
<p><em>The belief that complex systems require armies of designers and programmers is wrong.</em></p>
<p>Wirth couldn’t have been more correct on this point. He built an entire operating system and a new programming language with one collaborator. Yet we hear of teams increasing their engineering personnel by 10, 20, 50, even 100s of developers. It’s so common at this point it’s become a badge of honor and a means for proving the value of an organization for the next round of investors. There’s only one problem with this line of thinking: it’s wrong.</p>
<p>If these businesses truly relied upon so many engineers to achieve success, we would not have had <strong><strong>262,582</strong></strong> people laid off in 2023 alone as an industry (credit <a href="https://layoffs.fyi/">layoffs.fyi</a>). Businesses feel an inherent pressure to be first to market, otherwise they’ll have missed their window and their idea will be dead on arrival. They will do whatever they can to achieve success, including over-hiring on the basis that 10 developers will complete a project in 1/10th of the time of a single developer. As my co-founder, Justin Searls, describes in this <a href="../2023-04-03-never-staff-to-the-peak">thorough blog post</a>, staffing engineering teams to peak levels has a multitude of bad outcomes. Not just for the business, but as we’ve seen the last couple of years, for the engineering teams themselves.</p>
<p><strong>A Plea for Lean Software Teams</strong></p>
<p>If we are to get back to leaner and more efficient software development organizations, we need to solve both of these problems - too many features and too many developers.</p>
<p>Businesses need highly capable product managers who focus relentlessly on driving outcomes, not output. It’s exciting to see many of the agile consultants I used to work with focusing more in this space. It’s one of the reasons we’re extremely excited about <a href="../2023-11-08-test-double-acquires-pathfinder">working with Pathfinder Product</a> more closely. Great product managers are difficult to find, but when you have highly capable people in these roles, they have an outsized impact on the business.</p>
<p>Further, if we have learned anything in the last 3 years as an industry, it should be to strive for building small, highly efficient teams and avoiding bloated, overstaffed organizations at all costs. Larger teams move slower, create more incidental complexity, and are much more susceptible to the layoffs we’ve all been suffering through. Engineering leaders would be well served to focus on hiring smaller teams and providing them with sufficient time and support to create simple solutions that generate business value.</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-2021-12.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-2021-12.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-2021-12.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-2021-12.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-2021-12.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-2021-12.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>

+ 31
- 0
cache/2024/82b88d48d8043d79425ce8afd8dff42e/index.md View File

@@ -0,0 +1,31 @@
title: Echoing Wirth's plea for lean software
url: https://blog.testdouble.com/posts/2024-01-24-plea-for-lean/
hash_url: 82b88d48d8043d79425ce8afd8dff42e
archive_date: 2024-01-24

<p>Our industry lost one of its great minds on New Year’s Day as Niklaus Wirth passed at the age of 89. My first real computer programming class in high school used Pascal, which he designed in 1970, and the majority of my college courses used Modula-2, which he also designed in 1975. Both of these languages advanced the field of programming with innovations like modules, one-pass compilation, and concurrent programming. The type safety, clarity, and compiler support made these languages very approachable and easy to learn, likely keeping me on the path of a career in our industry. One of his greatest contributions to our field, that seems eerily prescient now, is his article “A Plea for Lean Software” published in Computer magazine in 1995.</p>
<p>The article laments the fact that we have been conditioned with significant advances in hardware, leading to software that is unnecessarily bloated. Humorously, the article begins by addressing how memory requirements jump “from several to many megabytes." I am writing this blog post in a browser window that is consuming 700MB while reviewing his article in Preview, clocking in at just shy of 1GB of memory consumption, almost proving his point 29 years later.</p>
<p><strong>We are spoiled</strong></p>
<p>The premise that software projects and programmers have become spoiled by the rapid advances in hardware is evident now more than ever. I carry around an iPhone 15 that has 2.15 teraflops of processing power. The most powerful supercomputer at the time I graduated college in 1998 could only do 1.6 teraflops. Looking back 25 years, it’s hard to imagine software development on such antiquated hardware, but I can attest that many of the systems we developed in the late 90s and early 2000s are still running to this day. Many of the biggest businesses with systems that need minimal downtime and no margin of error still run mainframe systems that were built in the 80s and 90s. Contrast that to the build in 3 months, run for 3 years, and then rewrite it all pattern that is so prevalent in businesses today and I think Mr. Wirth may have been on to something.</p>
<p>His article focused almost completely on the advances in hardware that were spoiling us, but 30 years later we also have massive advances in software that provide significant gains in programming efficiency. We operate on programming languages and frameworks that no longer require us to manually manage memory consumption. There’s largely no need for configuring parallelism in our systems for computational heavy tasks. In almost any web development language, we can largely pull in a number of prebuilt frameworks or packages that will solve a huge number of problems that he would’ve had to tackle himself. How then was he so much more productive than most of the teams I see today?</p>
<p>In the article, he’s trying to distill the lessons they learned while creating the Oberon System, a text-based user interface and operating system that he and a colleague completed in 3 years. It was based upon the programming language Oberon, which they also developed in this time. Keep in mind, they designed and developed this system 37 years ago, when their workstations likely had less than 2MB of RAM and were able to perform maybe 2M instructions per second. I struggle to imagine even the best programmers that I know creating an OS and a programming language under these constraints. What led to their success?</p>
<p><strong>MOAR FEATURES</strong></p>
<p>A point that he makes consistently throughout the article is that, as an industry, we have tendency to build a lot of features that no one really wants or needs.</p>
<p><em>Uncontrolled software growth has also been accepted because customers have trouble distinguishing between essential features and those that are just “nice to have.”</em></p>
<p>We see this all. the. time. Software businesses that are bootstrapped or early stage have to focus maniacally on only building the features that are proven to be critical to adoption. Then as adoption picks up, a second or third round of funding comes in, and these same businesses accelerate right out of the lean startup mindset. That first sales hire brings every idea to the table that a prospect may have mentioned into the newer and longer list of <strong>critical features</strong>. Immature product management does a poor job of validating the features and pruning the list into the set of features that truly drive outcomes.</p>
<p>It results in large systems that are extremely difficult for end users to operate within. Simplicity is inversely proportional to the number of features available for use.</p>

<img src="https://cdn-blog.testdouble.com/img/plea-for-lean/simplicity-graph.f6526546c7913435ddea37cc72251c703d73bd6a7fc05e8b2bc7f3dc0fa98798.png" alt="Simplicity vs Features" class="" loading="eager">

<p>When simplicity goes away, businesses are then forced to invest in other areas like documentation, training, and customer support. All for a user experience that is more likely to drive away new customers instead of achieving the original goal of bringing more users in. If you don’t believe me, ask yourself how often you see teams prioritize removing neglected features as part of their planning?</p>
<p><em>Any and all features mean design becomes more complicated and usability more cumbersome.</em></p>
<p>This incessant accumulation of features results in another cause for inefficiency: larger and larger software organizations.</p>
<p><strong>MOAR DEVELOPERS</strong></p>
<p>In my experience, overly complicated software designs are the number one reason for failure within software focused businesses. Yet engineering leaders rarely focus on addressing complexity within their systems. I can only assume that they believe the complexity is necessary and not incidental, which leaves them with only one option to pursue: throw more bodies at the problem.</p>
<p><em>The belief that complex systems require armies of designers and programmers is wrong.</em></p>
<p>Wirth couldn’t have been more correct on this point. He built an entire operating system and a new programming language with one collaborator. Yet we hear of teams increasing their engineering personnel by 10, 20, 50, even 100s of developers. It’s so common at this point it’s become a badge of honor and a means for proving the value of an organization for the next round of investors. There’s only one problem with this line of thinking: it’s wrong.</p>
<p>If these businesses truly relied upon so many engineers to achieve success, we would not have had <strong><strong>262,582</strong></strong> people laid off in 2023 alone as an industry (credit <a href="https://layoffs.fyi/">layoffs.fyi</a>). Businesses feel an inherent pressure to be first to market, otherwise they’ll have missed their window and their idea will be dead on arrival. They will do whatever they can to achieve success, including over-hiring on the basis that 10 developers will complete a project in 1/10th of the time of a single developer. As my co-founder, Justin Searls, describes in this <a href="../2023-04-03-never-staff-to-the-peak">thorough blog post</a>, staffing engineering teams to peak levels has a multitude of bad outcomes. Not just for the business, but as we’ve seen the last couple of years, for the engineering teams themselves.</p>
<p><strong>A Plea for Lean Software Teams</strong></p>
<p>If we are to get back to leaner and more efficient software development organizations, we need to solve both of these problems - too many features and too many developers.</p>
<p>Businesses need highly capable product managers who focus relentlessly on driving outcomes, not output. It’s exciting to see many of the agile consultants I used to work with focusing more in this space. It’s one of the reasons we’re extremely excited about <a href="../2023-11-08-test-double-acquires-pathfinder">working with Pathfinder Product</a> more closely. Great product managers are difficult to find, but when you have highly capable people in these roles, they have an outsized impact on the business.</p>
<p>Further, if we have learned anything in the last 3 years as an industry, it should be to strive for building small, highly efficient teams and avoiding bloated, overstaffed organizations at all costs. Larger teams move slower, create more incidental complexity, and are much more susceptible to the layoffs we’ve all been suffering through. Engineering leaders would be well served to focus on hiring smaller teams and providing them with sufficient time and support to create simple solutions that generate business value.</p>

+ 4
- 0
cache/2024/index.html View File

@@ -80,6 +80,8 @@
<li><a href="/david/cache/2024/e5c1ca8e3beeb0d256a064832c3566aa/" title="Accès à l’article dans le cache local : The personality of a personal website">The personality of a personal website</a> (<a href="https://manuelmoreale.com/the-personality-of-a-personal-website" title="Accès à l’article original distant : The personality of a personal website">original</a>)</li>
<li><a href="/david/cache/2024/7ed7f4aefae1b5af33b3ec1f607a633f/" title="Accès à l’article dans le cache local : L’Observatoire des perspectives utopiques">L’Observatoire des perspectives utopiques</a> (<a href="https://lobsoco.com/perspectives-utopiques-vague-3/" title="Accès à l’article original distant : L’Observatoire des perspectives utopiques">original</a>)</li>
<li><a href="/david/cache/2024/9bc04d41d25fc73391116d99b7259a3d/" title="Accès à l’article dans le cache local : notes">notes</a> (<a href="https://www.la-grange.net/2023/07/10/notes-train" title="Accès à l’article original distant : notes">original</a>)</li>
<li><a href="/david/cache/2024/112d32ccefb9aec48180de42e1fe1534/" title="Accès à l’article dans le cache local : Quand je serai bien vieux">Quand je serai bien vieux</a> (<a href="https://n.survol.fr/n/quand-je-serai-bien-vieux" title="Accès à l’article original distant : Quand je serai bien vieux">original</a>)</li>
@@ -128,6 +130,8 @@
<li><a href="/david/cache/2024/291cddda62f18ec9355ec98761b7e9d9/" title="Accès à l’article dans le cache local : Writing with AI">Writing with AI</a> (<a href="https://ia.net/topics/writing-with-ai" title="Accès à l’article original distant : Writing with AI">original</a>)</li>
<li><a href="/david/cache/2024/82b88d48d8043d79425ce8afd8dff42e/" title="Accès à l’article dans le cache local : Echoing Wirth's plea for lean software">Echoing Wirth's plea for lean software</a> (<a href="https://blog.testdouble.com/posts/2024-01-24-plea-for-lean/" title="Accès à l’article original distant : Echoing Wirth's plea for lean software">original</a>)</li>
<li><a href="/david/cache/2024/ea2cfc9aa425a6967d2cacd9f96ceb9e/" title="Accès à l’article dans le cache local : Ask LukeW: New Ways into Web Content">Ask LukeW: New Ways into Web Content</a> (<a href="https://lukew.com/ff/entry.asp?2008" title="Accès à l’article original distant : Ask LukeW: New Ways into Web Content">original</a>)</li>
<li><a href="/david/cache/2024/4a56aa5497e68df0c5bb1d5331203219/" title="Accès à l’article dans le cache local : When “Everything” Becomes Too Much: The npm Package Chaos of 2024">When “Everything” Becomes Too Much: The npm Package Chaos of 2024</a> (<a href="https://socket.dev/blog/when-everything-becomes-too-much" title="Accès à l’article original distant : When “Everything” Becomes Too Much: The npm Package Chaos of 2024">original</a>)</li>

Write Preview
Loading…
Cancel
Save