More on this book
Community
Kindle Notes & Highlights
Read between
February 27 - March 17, 2022
We build our computer systems the way we build our cities: over time, without a plan, on top of ruins. —Ellen Ullman
David L. Goodstein published his book States of Matter with the following introduction: Ludwig Boltzmann, who spent much of his life studying statistical mechanics, died in 1906, by his own hand. Paul Ehrenfest, carrying on the work, died similarly in 1933. Now it is our turn to study statistical mechanics.
This is a book about how to run legacy modernizations, a topic many software engineers regard as slow-moving career suicide, if not the prologue to a literal one.
Restoring legacy systems to operational excellence is ultimately about resuscitating an iterative development process so that the systems are being maintained and evolving as time goes on.
Like pottery sherds, old computer programs are artifacts of human thought. There’s so much you can tell about an organization’s past by looking at its code.
The subtext behind the phrase legacy technology is that it’s also bad, barely functioning maybe, but legacy technology exists only if it is successful.
Failure is predictable because so many software engineers think the conversations about modernizing legacy technology are not relevant to their careers.
exasperated, I complained to my boss, “Why am I running a legacy modernization on a three-month-old system?” To which he retorted, “Serves you right for not showing up three months ago.”
It is easy to build things, but it is difficult to rethink them once they are in place.
Legacy modernizations are hard not because they are technically hard—the problems and the solutions are usually well understood—it’s the people side of the modernization effort that is hard.
We are horrified to discover that most people do not actually care how healthy a piece of technology is as long as it performs the function they need it to with a reasonable degree of accuracy in a timeframe that doesn’t exhaust their patience.
System is a troublesome word in technology conversations as it seems you can never find a group of engineers who agree where its boundaries are.
When you venture into the world of legacy modernization, you quickly realize that mainframes are still everywhere—in banks, in government, buried deep in the foundation of civil society.
how is the cloud any different from old time-sharing schemes on mainframes?”
“We started with thin-client mainframe green-screen terminal applications, then they wanted us to migrate to fat clients on PCs, now they want APIs with thin clients again.”
The first mistake software engineers make with legacy modernization is assuming technical advancement is linear. With that frame of mind, anything built in older design patterns or with an older architectural philosophy is inferior to newer options. Improving the performance of an old system is just a matter of rearranging it to a new pattern.
progress in technology is not linear. It’s cyclical.
Alignable differences are those for which the consumer has a reference point. For example, this car is faster than that car, or this phone has a better camera than that phone. Nonalignable differences are characteristics that are wholly unique and innovative; there are no reference points with which to compare.
As a company iterates to improve a certain characteristic of the product, it ultimately makes the product less desirable for the group of existing customers. Companies do this with the hope that a larger group of new customers will make that loss irrelevant.
Engineers praised the publish/subscribe model of Kafka as superior to the hub-and-spoke model of Enterprise Service Buses (ESBs). ESBs were a single point of failure and an anti-pattern for service-oriented architecture. Then Kafka added its Connect framework (version 0.9) and its Streams API (0.10), which reintroduced many of the core concepts of ESBs.
Service Dominate Logic(S-D Logic). S-D Logic says that consumer value is not created by companies producing products but by an active collaboration between many actors. According to S-D Logic, consumers are not passive, thoughtless sheep whose wants and desires are engineered for them by industry. Instead, consumers actively participate in creating the markets that are leveraged to sell them things.
Anyone who has ever tried to start their own business will tell you the existence of a problem does not mean there’s a market for solving it.
Computers are data processors. They move data around and rearrange it into different formats and displays for us. That’s about all they do,
All advancements with data processors come down to one of two things: either you make the machine faster or you make the pipes delivering data to the machine faster.
A supercomputer in 1985, for example, had about as much processing power as an early-generation iPhone.
The National Science Foundation Network, which would eventually become the backbone of the early internet, offered 56kbps in the 1980s.
It’s unlikely that the private sector ever would have built the internet once it had unlocked the personal computing market. Computer manufacturers were benefiting much more financially from their proprietary standards at the time.
What’s interesting about the internet is that it is the only modern-day communication medium that has been historically flat-rate priced.
Adopting new practices doesn’t necessarily make technology better, but doing so almost always makes technology more complicated, and more complicated technology is hard to maintain and ultimately more prone to failure.
It’s important to understand that we advance in cycles, because that’s the only way we learn how to avoid unnecessary rewrites and partial migrations. Changing technology should be about real value and trade-offs, not faulty assumptions that newer is by default more advanced.
The odds of a modern piece of technology perfectly reflecting an older piece of technology are as likely as finding two days where every star in the sky had the exact same position.
Computers wouldn’t be developed to work with monitors until 1964 when Bell Labs incorporated the first primitive visual interface into the Multics time-sharing system.
In the 1960s, psychologist Robert Zajonc conducted a series of experiments documenting how even a single exposure to something increased positive feelings about it in later encounters.
mere-exposure effect. Simply being exposed to a concept makes it easier for the brain to process that concept and, therefore, feels easier to understand for the user.
If Dennis and Ken had a Selectric instead of a Teletype, we’d probably be typing “copy” and “remove” instead of “cp” and “rm.” Proof again that technology limits our choices as often as it expands them.
A century ago, fast typists were jamming their keyboards, so engineers designed the QWERTY keyboard to slow them down. Computer keyboards don’t jam, but we’re still living with QWERTY today.
ALGOL60 has profoundly shaped the structure and syntax of virtually every modern language, but you’d struggle to find a programmer today who has ever even heard of it.
COBOL was a language built for people who did not want to understand how the computer worked; they just wanted to get the job done.
Making programming more accessible and code human-readable was considered an anti-pattern, dumbing down the beauty of programming for an unworthy audience.
Roughly three networks of people were programming computers between the 1950s and 1970s: scientists and mathematicians, data processors, and academics or computer researchers.
The design of the language is never what’s important; it’s the people.
ALGOL60 may not have been used to build many applications, but it was what the Association for Computing Machinery (ACM) used to describe algorithms in textbooks and academic sources for more than 30 years.
The lesson to learn here is the systems that feel familiar to people always provide more value than the systems that have structural elegances but run contrary to expectations.
Making people think adds friction and increases the odds of failure, even if the new interface is better and more consistent with the overall vision of the product.
Engineers tend to overestimate the value of order and neatness. The only thing that really matters with a computer system is its effectiveness at performing its practical application.
The incentives that reward individual software engineers for their uniqueness, their ability to do new things, or to do old things in innovative ways are still present, even if the desire to publish papers in academic journals has been supplanted by the desire to write popular blog posts.
iterating on existing solutions is more likely to improve software than a full rewrite.
The dangers of full rewrites have been documented. Joel Spolsky of Fog Creek Software and Stack Overflow described them as “the single worst strategic mistake that any software company can make.”
Chad Fowler, general manager of startups at Microsoft, describes it this way: Almost all production software is in such bad shape that it would be nearly useless as a guide to re-implementing itself. Now take this already bad picture, and extract only those products that are big, complex, and fragile enough to need a major rewrite, and the odds of success with this approach are significantly worse.14
Zajonc’s mere-exposure effect has an upper bound. There’s a point where familiarity breeds contempt.
