Lego Mindset vs. Woordworking Mindset by Scott Stevenson:
- main concepts:
- legibility (Lego), for which S. Stevenson links to A Big Little Idea Called Legibility (Venkatesh Rao) (oddly, calls that blog post a “seminal work” when it’s just a summary of “Seeing Like a State” by James Scott)
- S. Stevenson misattributes the forest analogy to Venkatesh Rao! That’s analogy from the first few chapters of Seeing Like a State, so it seems S. Stevenson isn’t familiar with Seeing Like a State and may not have gone too deep on Rao’s summary.
- the alternative S Stevenson gives to legible (Lego in his analogy) work is “object-level” work (woodworking) which is focused on an outcome (note: this part is very different from Seeing Like a State, where actually the legible solutions are more focused on outcomes!)
- legibility (Lego), for which S. Stevenson links to A Big Little Idea Called Legibility (Venkatesh Rao) (oddly, calls that blog post a “seminal work” when it’s just a summary of “Seeing Like a State” by James Scott)
- claims:
- (attempts to justify, but it’s a weak claim anyway) a legible system is not necessarily better
- (unjustified, also used as evidence, but I happen to agree) contra stereotype, many senior engineers do woodworking-style work
- (attempts to justify, but it’s a weak claim anyway) no one metaphor is the best way to direct work
- other observations by the author:
- says that after the woodworking has happened, legos may emerge that can be used for future work, as a product for other engineers. These can be simple and legible.
- my observations and where I might disagree:
- I don’t see much connection with the concept of legibility used here and the one from Seeing Like a State. Seeing Like a State introduces new terminology and goes to great pains to define it and the terminology seems to be misapplied here. Some differences:
- S. Stevenson is talking about how we build but Scott (in Seeing Like a State) is talking about how we measure to control. These are entirely different things! In fact, a central thesis J. Scott argues for is that how we measure (for the purposes of control) affects how we build.
- Examples of making codebases legible that are more S. Scott-ian are looking at lines of code, cyclomatic complexity, test coverage, etc. These have nothing to do with things that Stevenson talks about like “reusability”, which are non-legible in S. Scott’s terminology!
- S. Stevenson is talking about how we build but Scott (in Seeing Like a State) is talking about how we measure to control. These are entirely different things! In fact, a central thesis J. Scott argues for is that how we measure (for the purposes of control) affects how we build.
- The blog post is pretty vague and doesn’t have real examples, hard to engage with
- S. Stevenson never defines his notion of “leigiblity” (which apparenlty has nothing to do with J. Scott’s).
- Based on the examples, here’s what S. Stevenson may have in mind:
- reusable
- not chaotic
- But note that the meaning of “chaotic” as “sensitivity to initial conditions” doesn’t really seem to apply to software, not sure what S Stevenson is taling about here. He seems to be talking about the behavior or organization of a company or team rather than the codebase/system itself, which hardly seems relevant. A chaotic company can build software of any kind at all.
- solve many problems rather than one
- scalable
- But these are heterogeneous criteria! I can see some codebases/systems meeting a few of these criteria but not others. I don’t see this (quasi) definition adding any clarity.
- Based on the examples, here’s what S. Stevenson may have in mind:
- Given “legibility” is some grab-bag of good features, the only way for me to refute or disagree (accepting the nonstandard and vague definition) is to say that every codebase/system must be reusable+not-chaotic+general+scalable. I don’t know why anyone would make such a claim, so it’s hard to disagree to the extent that S. Stevenson is saying anything at all.
- If I’m being as charitable as possible, I’d:
- take the main claim of the paper to be that “good” software need not be reusable, especially at the beginning before the particular problem is solved. Sure. I think this claim is made much better in other places, especially in the context of discussion of prremature abstraction or in A Philosophy of Software Design.
- If I’m being as charitable as possible, I’d:
- I don’t see much connection with the concept of legibility used here and the one from Seeing Like a State. Seeing Like a State introduces new terminology and goes to great pains to define it and the terminology seems to be misapplied here. Some differences:
As of 2024-12-30 ChatGPT does a better job applying the concept of legibility to software and drawing conclusions about good software: https://chatgpt.com/share/677283d7-115c-8003-8cee-e2c3aa3d3a60 (outside of the “speculative” section)