Sometimes I forget about things I've said that could be useful. 1/

https://twitter.com/rajkatie/status/1353961778691133441

The idea behind this one is that you learn a lot about the quality of a design by trying to test it, but it happens at (at least) two levels. 2/

One of the things I learned from @KentBeck years ago was to see cohesion in terms of divergent change rates. If you have a class and there's a set of methods that you tend to change together while leaving others alone, that set of methods could be a separate responsibility. Once I saw this, I went so far as to write a script to mine classes in Git and find clusters of methods that all seemed to change at the same time.

Thinking about emergence and math this morning, and how we can deal with emergence if we systematically discard pieces of the math toolkit.

The fascinating thing, though, is that we don't end up with the empty set (no pun intended). Emergence is when the whole is different/greater than the sum of its parts.

Important question: when doesn't that happen?

Aerto (or Airto) is when structure fulfills. Specifically, it is when growth occurs without creating new structure at the same scale. An empty swimming pool is slowly filled with water - this is Aerto.

It's amazing how much knowledge dissipates in software development. Code, in particular, is lossy.

There's a quality in design that I like, but it's hard to talk about. I call it 'sweetness.' 'Sweetness' is when several design criteria are satisfied by the same thing. The thing that makes this hard to talk about is that it is often confused with dependency. It actually is a form of dependency, but it has some positives that sometimes outweigh the negatives.

The thing that makes this different from most software development (including Agile) is treating small teams as small companies. Teams have fitness functions in relation to overall business.

jasoncrawford.org/two-pizza-teams What we seem to be discovering is that small teams/products are better.

They are so much better that we are better off when big companies act as a loose consortium of small companies.

There is so much in the process space which is about fixing people or positing a model about how people should be for software development.

What if we flipped it and thought about working with people's natural inclinations more? It may not always work, but it's an avenue. The place where I think about this the most now is solo work. Some people are more naturally collaborative than others. And that's good because large complex systems require a lot of coordination.

I really think that 'community' is one of the most abused words in the English language today. I flinch whenever I hear it in tech circles, much like my reaction to the word 'enterprise.' There's a case for using the word below the Dunbar Number (150) but in the space between that and the next order of magnitude, it breaks down.

The best design books are not about design. Instead, they reveal forces that you should be aware of when you design. Here are three of my favorites: The Lathe of Heaven - Ursula K. Le Guin

To learn the value of sufficient insight when problem solving.

Inheritance might be the most unjustly maligned language feature. The amount of effort that has been expended at the language level to tame it over the decades has been extraordinary.

Visited Frank Lloyd Wright’s Fallingwater the other day. The amount of thought that went into that design is stunning. Cantilevers were a motif. Even the stone in the walls and the furniture (which he designed) were cantilevered.