Fred Brooks, Fowler and what doesn't change in the profession

I keep browsing my notes, especially the ones I used to create talks. Notice that some themes keep coming back.

One is something I use a lot: you are not paid to write code (in Portuguese). The essence of a problem we want to solve is tied to what needs to be built. A process of discovery and refinement to define scope and requirements very well. Fred Brooks shows up a lot here.

The other theme is this cross-pollination, how work has become more complex, especially in corporate environments, where a single specialization isn’t enough, given all the communication we have to do with other teams. Looking at a problem more broadly. From a higher level, you end up picking up needs on a horizontal plane: skills that used to have nothing to do with your profession.

The quotes that repeat the most in my slides:

“The hardest single part of building a software system is deciding precisely what to build.”

Fred Brooks, No Silver Bullet, 1986. In a deck from this year I noted that the sentence aged well. If code became cheap and disposable, what is left that is hard, and valuable, is exactly what he pointed out. Deciding what.

“The complexity of software is an essential property, not an accidental one.”

Fred Brooks, in the same text. It is the split between accidental and essential complexity. The accidental one is what tools knock down, one layer at a time. The essential one is still there.

“When anyone can build anything, knowing what’s worth building becomes the skill.”

Kent Beck, in The Pragmatic Engineer, December 2025. Fifty years after Brooks, the same conclusion from the other side: when anyone builds anything, knowing what is worth building, and what is worth keeping, is the scarce skill.

“Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.”

Grady Booch. If architecture is what is expensive to change, AI just moved the yardstick: writing got cheap, changing is still expensive.

“A business analyst writing code out of curiosity, a front-end engineer dabbling in DevOps, a data engineer trying product analysis: each cross-pollination broadens both the individual and the team.”

Martin Fowler, Expert Generalists.

“T-shaped developers combine depth with breadth. They can dive deep into specific problems but also understand how it fits into a larger system.”

Werner Vogels, CTO of Amazon. And he is not the only one saying it: Osmani, Fowler, Bill Gates.

“Junior engineers often try to widen the horizontal bar too fast without ever digging deep. Senior excellence requires that vertical anchor.”

Addy Osmani, engineering lead at Google Chrome. The horizontal bar is context, the vertical one is confidence.

“Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.”

Conway’s law, from How Do Committees Invent?, 1968.

“Code is suddenly free, ephemeral, malleable, discardable after single use.”

Andrej Karpathy, Year in Review 2025.