You may have noticed, I basically live my work life from quotes. Memes, too, but that’s another story. Anyways, I thought for today’s blog post I would share with you some of my favorite quotes, why I think they are insightful, and how I apply them.
Speed of iteration beats quality of iteration.– John Boyd
One of my favorite quotes, and a fundamental aspect of Agile. Colonel John Boyd, sometimes referred to as the “Father of the F-16”, was a United States Air Force pilot who became well-known in military circles for his theories on movement and strategy, which eventually grew beyond military tactics and became relevant in business as well. One of his foundational concepts was the concept that the entity that reacts faster would outperform an entity that reacts slower, even if the quality of the slower reactions was higher. This is the key concept of agile, that the focus is on short sprints and reactivity, being able to constantly adjust to ever changing requirements and conditions. Col Boyd’s biography, Boyd: The Fighter Pilot Who Changed the Art of War, is well-worth a read if you are interested in his underlying theories of strategy and planning.
One of my most productive days was throwing away 1000 lines of code.— Ken Thompson
When in doubt, use brute force.— Ken Thompson
Ken Thompson is an old-school computer science genius of the highest order. Not only did he help invent both Unix and C, he has remained relevant in modern industry by also helping invent Go. Given those credentials, I would listen carefully to anything this person has to say.
Both of these quotes I interpret as coming from the same source idea, that is, the idea of simplicity and economy, not just of code but also of time. I’m sure many of you are familiar with the “second-system effect”, even if in practice if not by name. Have you ever tried to work with a software system, either adding a piece of functionality or fixing a bug, only to discover that the software system has grown into a complex maze of abstractions and configurations and modules and factories, all in the name of “flexibility”? I frequently re-phrase this as “just write the darn if statement”, that is, if you’ve found some edge case or some piece of capability to add, you don’t always need to refactor the entire system to support plugins and inversion of control and dependency injection, you sometimes just add an “if” statement in a key place and get the task done. This needs to be balanced, of course, with the creation of technical debt, but also if your customer is waiting on a bugfix and you can slap in an if-statement and get the bug fixed in a day, that might be a better approach than taking 3 sprints to rewrite your core framework.
(Note that this applies to business and strategy decisions as well. Don’t overcomplicate things that can be easily solved with something simple.)
The first 90 percent of the code accounts for the first 10 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.—Tom Cargill, Bell Labs
A simple idea that many people know already. Make sure you factor in time for debugging and hardening, addressing external dependencies and schedule risks, and dealing with all of the technical debt that you accumulated during the life of the project.
Do not develop an attachment to any one weapon or any one school of fighting.— Miyamoto Musashi
Another simple idea that technologists should do well to remember. I remember one time working on a project that was a combination of hardware and software. During the integration test phase, we discovered a facepalm defect…the hardware devices had four output wires that drove an LED display, but the software driver assumed the wires were in order from 1 to 4 in the wrong direction, so the LED display was not working. The hardware engineer wanted to redo the fabrication by fixing the wires, but even a rudimentary cost analysis showed that the trivial software change was much less expensive and shorter than redoing the production line. But the person was a hardware engineer, so they were used to only thinking about things in terms of hardware. Don’t lose sight of the big picture, and be willing to explore tools, ideas, and solutions other than what you are comfortable with, if it means a better approach.
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”— Brian Kernaghan
“A cardinal, fundamental law of programming: It’s harder to read code than to write it.”— Joel Spolsky
Two quotes, from two people from vastly different software domains, yet together provide a key concept that is important to understand from a software maintenance perspective. Making an intentional effort to write code more simply, even if it means not being able to use your awesome clever tricks, allows the code to be more maintainable in the future. (I am aware this does not work in all situations…sometimes the code has to do something really hard, or has to be really performant, so those complex tricks have to be there.)
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.— Conway’s Law, by Fred Brooks
“Looking into the VAX, West had imagined he saw a diagram of DEC’s corporate organization”— From The Soul of a New Machine, by Tracy Kidder
My takeaway from these quotes is actually a corollary, as opposed to the quote itself. The velocity of a system, whether it is software, hardware, or a business process, is frequently constrained by the higher-level communication channels. The bottlenecks appear when information has to be moved between one subsystem to another. i.e. retrieving data from disk rather than RAM, making a REST call instead of a local lookup, or an approval mechanism that has to cross organizational lines. If you are designing for speed and velocity, keep this in mind. Move frequently accessed data closer to the source, and try to create business processes that minimize the movement of the thread across too many lines on the org chart.
These are a few of my favorite quotes I’ve amassed over the years, and how I apply them to my strategy and planning.