Quotes

In our search for measures of delivery performance that meet these criteria, we settled on four: delivery lead time, deployment frequency, time to restore service, and change fail rate.

This is one of the main points of the book in terms of what you should be measuring. The key thing all this achieves is making changes faster. If changes can be made quickly then developers can ship much easier. You can deploy and roll back changes faster means they’ve less risk when they go out. This gives you speed. If you’ve to take days or weeks to think about what change you can make and how you need to make it, then it slows down everything and in fact increases the risk of the change. Instead look to reduce the risk and increase the speed. Proper monitoring for the changes should exist so they can be detected and rolled back quickly.

In continuous delivery, we invest in building a culture supported by tools and people where we can detect any issues quickly, so that they can be fixed straight away when they are cheap to detect and resolve.

A key goal of continuous delivery is changing the economics of the software delivery process so the cost of pushing out individual changes is very low.

For lots of metrics you should avoid making a particular metric the goal as you’re likely to end up with everyone optimising for that. This is probably no exception so you’ve to be careful

For all the gains, few outside the office shared the same regard for the group’s approach. When Berlekamp explained his firm’s methods to business students on Berkeley’s campus, some mocked him. “We were viewed as flakes with ridiculous ideas,” Berlekamp says. Fellow professors were polite enough not to share their criticism and skepticism, at least within earshot. But Berlekamp knew what they were thinking. “Colleagues avoided or evaded commenting,” he says.

Over and over throughout this book there are many instances of how success never was really obvious. Nowadays the fund is one of the most successful ever but back then it was far from obvious that they were making any real headway - most believed it was a curious idea but wouldn’t unseat the “professional” bankers and traders who would make most of the money forever

Berlekamp told Simons he was unsure what to do. Simons couldn’t understand his indecision. “Elwyn, when you smell smoke, you get the hell out!” Simons told him. Straus closed the brokerage account and shifted their trades elsewhere. Months later, Mahlmann resigned from Stotler and the Chicago Board of Trade; two days later, Stotler filed for bankruptcy. Eventually, regulators charged the firm with fraud. Simons and his firm had narrowly escaped a likely death blow.

Another quote is this one where they got caught in a near miss of the collapse of Stotler Group, a trading firm they did a lot of business with. If the didn’t move their trades, they probably would have had

When the U.S. transferred the canal to Panama in 1999, the waterway’s original locks from 1914 were almost obsolete as they were too narrow for many U.S. Navy ships. Panama embarked on an overhaul to expand canal capacity and boost profitability. It invested more than $5 billion to build larger locks that boosted revenue and the number of ship passages to as many as 36 a day. That sparked its transformation into a vital link for global trade that also triggered investment at U.S. ports to handle the larger tankers going from one coast to the other with oil and liquefied natural gas. The canal now generates some $5 billion in annual revenue. The government keeps about half and the rest covers operating costs and investments.

https://www.wsj.com/world/americas/panama-canal-us-american-history-e79a34f0

It cost about the same to renovate the canal in 1999 as it brings in today in income. Taking inflation into account it cost about $9.47 billion back then in todays dollars. Not a bad return on investment

I guess the moral of the story is you can’t just build something once and assume it’ll be there forever, you have to keep reinvesting over and over to keep up with the times or else people will find other ways around it.

I’ll elaborate my earlier rule of thumb: anyone should be able to bring in a clean machine, check the sources out of the repository, issue a single command, and have a running system on their own environment.

https://martinfowler.com/articles/continuousIntegration.html

Sounds simple but so many miss this. Often through no fault of the project itself but through dependencies or version mismatches, things out of date or not installed.

We should reduce the cognitive load in our projects as much as possible. When reading code, you put things like values of variables, control flow logic and call sequences into your head. The average person can hold roughly four such things in working memory. Once the cognitive load reaches this threshold, a significant effort is required to understand things.

https://github.com/zakirullin/cognitive-load

It’s a handy rule of thumb to keep in mind when doing anything, not just writing code. In code, try keep things at the high level and not to next details within details too much. If you can make things like functions or files encapsulate all the logic they need and be as standalone as possible then the developer can ignore much of the world going on around them and focus just on the changes here. However if the function has side effects on outside code or relies on many different pieces to function then anyone will struggle to understand it.

It’s something to keep in mind when you see large files and why things should be kept fairly simple. Again it is a rule of thumb and there are situations where it can be broken but in general try keep cognitive load low

The past while I’ve started to take a random quote and put it on this blog. Sometimes there’s commentary and sometimes it is just the quote. I’m not sure how useful this all is to the random person going by but the target market for this website is me, not anyone else. The purpose is to build up a habit and an ability to write and to communicate. So this is what this is about

It is inspired heavily by a few different sources, namely this post about creating a linkblog by Simon Wilson and Marginal Revolution by Tyler Cowen. In both of those, while being blogs, the main content is usually short pieces or links to other places on the web with short sentences or paragraphs exploring the link. I’m thinking to start at a relatively easy place that is what I can do.

The easiest source for content on this is using Readwise daily review. In that it gives me 5 random quotes I’ve saved over the years. The thing is I never really use those quotes for anything and reading them doesn’t give me much benefit. Read anything about how to improve your learning and the most beneficial ways is to do spaced repetition and to make use of the learning - put it in your own words. So that is what this blog is about. Taking those quotes and putting my own words below them. Much of the time there won’t be much said and what will be said won’t make much sense. But

One of the differences between regular developers and software craftsmen is that software craftsmen are on a mission. They are on a mission to make things better, to deliver value to their clients, and to inspire people around them. They are not afraid to lead the way and drive changes. For software craftsmen, striving to always do their best is just a natural state of mind.

The entire premise of the book is about getting us to look at software as a craft. So take the time and energy to make things better for everyone rather than just seeing it as a job to get done and get to the next thing. Taking time like this leads to better results in the short and the long term

The pioneers of the Industrial Revolution valorized precision, and as the revolution gathered speed, requirements for precision grew ever more stringent. In the 1770s, James Watt proudly declared that the cylinders of his steam engine were bored to the precision of 1/20 of an inch. By the 1850s, the self-acting machines of Joseph Whitworth aimed for a precision of 1/10,000 of an inch.  Eighteenth-century England stood out in its ample supply of craftsmen able to do high-precision work. From 1700–1800, England saw a doubling in the number of clockmakers and instrument makers, according to evidence collected by Kelly and Ó Gráda. Besides clocks, these producers made instruments for mathematical disciplines such as surveying, navigation, bookkeeping, and astronomy.

https://worksinprogress.co/issue/how-mathematics-built-the-modern-world/

See also: Exactly: How Precision Engineers Created the Modern World - Simon Winchester

Monju is an extreme case, but it’s not in a category by itself. Far from it. Nuclear power plants are one of the worst-performing project types in my database, with an average cost overrun of 120 percent in real terms and schedules running 65 percent longer than planned. Even worse, they are at risk of fat-tail extremes for both cost and schedule, meaning they may go 20 or 30 percent over budget. Or 200 or 300 percent. Or 500 percent. Or more. There is almost no limit to how bad things can get, as Monju demonstrated so spectacularly.

How Big Things Get Done - Bent Flyvbjerg and Dan Gardner

What was so spectacular about Monju was that it was a nuclear power plant that over the entire lifetime of the project from when it started to generate electricity in 1994 to when it was decommissioned in 2016, a lifetime of only 22 years, it contributed to the grid for roughly one hour. For about 10 billion dollars. The table below gives a general timeline of the main events but yeah it was a spectacular failure.

How does the book propose we avoid these spectacular failures? The key issue with these

The easiest, most straightforward way to create a great product or service is to make something you want to use. That lets you design what you know—and you’ll figure out immediately whether or not what you’re making is any good.

That’s a quote from Rework by Jason Fried and David Heinemeier Hansson.