davidbgk
/
larlet-fr-david-cache


			
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201
							<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="en">
<!-- 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>