I’m a sucker for lists that contain pithy nuggets of truth. Here’s two great ones I found this week:
Some of my favorite statements, in no particular order:
If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system
Every system eventually sucks, get over it
Software engineers should write regularly
Always strive to build a smaller system
KISS, don’t be afraid, and boring > cool
The bottleneck is almost always the database
Technologists are particularly susceptible to recency bias. It’s one reason why I try to read older computer science literature from time to time (especially work from the 60s and 70s). The Mythical Man-Month is my canonical example; it should be required reading for everyone who works with technology. The Psychology of Computer Programming contains timeless truths of what it takes to lead a team of software engineers. Donald Knuth’s The Art of Computer Programming is a dense, three volume work, but much treasure lies within. I’ve only finished the first book, but I came away with tremendous respect for the geniuses that paved the way for us fortunate souls who have IDEs, fast compilers, and gigabytes of RAM.
Today I read On the Criteria To Be Used in Decomposing Systems into Modules, a research paper by D.L. Parnas of Carnegie-Mellon University, published in 1972. While the details of the middle section weren’t terribly interesting, it’s the bookends of introduction and conclusion that impressed me. The benefits of two-pizza teams were clearly understood fifty years ago, for example (“separate groups would work on each module with little need for communication”) and the paper lays out a novel approach to decomposition (to me, at least):
“We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.”
The above resonates with prior posts I’ve written on abstractions, especially Out of Sight, Out of Mind. If the goal of abstraction is to hide difficult detail, we ought to modularize with that goal front-and-center.
I was privileged to have access to computers from an early age, from the humble TI-99/4A of my early elementary years to a snappy Pentium in high school (can’t remember the exact model, but it was pretty expensive; perhaps the 133MHz version?) The influence this access had on my life cannot be overstated.
Now that I’m firmly in middle age, and on a career path where I’m regularly evaluating technical talent, I’m reminded of that privilege, and how so many didn’t have it then, and some still don’t have it now. How much untapped potential there must be within these groups!
If we’re going to overcome the lack of diversity in tech, it starts with access; early access, when life-long perceptions are formed. As the saying goes: the best time to plant a tree is 25 years ago, but the second best time is today. Gotta get planting!