Showing posts with label software. Show all posts
Showing posts with label software. Show all posts

Tony Hoare introduced Communicating Sequential Processes (CSP)

Mike's Notes

Alex introduced me to Tony Hoare.

"As far as I remember, the main focus of messaging is on exchange protocols—a whole separate field of algorithmic analysis of interacting processes. Hoare wrote a treatise on this back in the last century, "Interacting Sequential Processes"—I think that's what it's called." - Alex Shkotin

Resources

References

  • Learning CSP, by Tony Hoare
  • Communicating Sequential Processes by Tony Hoare, ACM

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

31/01/2026

Tony Hoare introduced Communicating Sequential Processes (CSP)

By: 
Stanford: Copied 31/01/2026

Sir Charles Antony Richard Hoare (/hɔːr/ HOR; born 11 January 1934), also known as C. A. R. Hoare, is a British computer scientist who has made foundational contributions to programming languages, algorithms, operating systems, formal verification, and concurrent computing.[3] His work earned him the 1980 ACM Turing Award, usually regarded as the highest distinction in computer science.


 

Tony Hoare, winner of the Association for Computing Machinery's A.M. Turing Award, discusses the origin of his model of "Communicating Sequential Processes" and the central importance of keeping processes from directly accessing the state information of other processes. This clip taken from an interview conducted with Hoare by Cliff Jones for the ACM on November 24. 2015. Video of the full interview is available as part of Hoare’s ACM profile at https://amturing.acm.org/award_winners/hoare_4622167.cfm


On Design

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." - Tony Hoare

Introduction

Tony Hoare introduced Communicating Sequential Processes (CSP) in 1978 as a language to describe interactions between concurrent processes. Historically, software advancement has mainly relied upon improvements in hardware that create enable faster CPUs and larger memory. Hoare recognized that a machine with hardware that is 10 times as fast running a code that consumes 10 times more resources is not an improvement.

While concurrency has many advantages over traditional sequential programming, it has failed to gain a popular audience because of its erroneous nature. With CSP, Hoare introduced a precise theory that can mathematically guarantee programs to be free of the common problems of concurrency. In his book, Learning CSP (the third most quoted book in Computer Science), Hoare uses calculus to show that it is possible to work with deadlocks and nondeterminism as if they were terminal events in ordinary processes. By reducing the errors of CSP, Hoare has enabled computer scientists to fully exploit the capacity of CPUs.

What is concurrency?

The ordinary task of doing your laundry illustrates the basics of concurrency. There are two ways to finish two loads of laundry:

  1. Put 1st load in washing machine → put 1st load in dryer → fold 1st load → put the 2nd load into the washing machine → repeat process.
  2. Put 1st load in washing machine → put 1st load in dryer → put 2nd load in washing machine → etc…

Clearly, the second method is quicker and better utilizes resources. If the first load is in the dryer, the washing machine isn’t being used and should be used by the second load. This is the basics of concurrency.

Historical Information

The earliest ideas for concurrent processing arose naturally in the 1960’s because of scarce resources. At that time, processing power was expensive, and it was wasteful for a processor to have to wait while it communicated with slow peripheral equipment or human (Hoare, Learning CSP).

Ex: The task of performing a simple addition problem shows how concurrency can greatly improve computational efficiency. Adding numbers requires three parts:

  1. Ask user for input numbers
  2. Performing calculation
  3. Printing the answer

Problems of concurrency and Hoare’s solution

While concurrency offers great potential for faster computation, it is not without fault. Unlike parallelism, where n tasks run on n processors, in concurrency, n tasks run on 1 processor. Because the amount of resources doesn’t increase, programs that need to use the same resource must wait.

  1. The amount of time user waits increases linearly
  2. The amount of storage space needed increases with number of jobs
  3. Difficulty verifying program correctness

The difficulty of verifying program correctness has been the primary hindrance in the field. Programmers have shied away from parallel programming because errors that arise in this method of programming are notoriously difficult to track down. Programs are often prone to errors that not obvious and surface under arbitrary and unrepeatable situations. The complex nature of concurrency leaves the programmer in doubt. Programmers often resort to exhaustive search tactics to find errors:

Testing the code rigorously to sort out obvious concurrency issues and hoping that all problems have been resolved

Completely follow design patterns and guidelines for concurrent programming. This method is limited in its applicability.

OR...

Hoare’s approach CSP uses mathematical deductions to prove that a program is error free. Through the application of CSP, programmers no longer search for bugs in written programs, but rather can write programs that are logically guaranteed to be correct.

General terms in CSP

Alphabet- set of events which are considered relevant for a particular object. The alphabet of a process is enclosed within curly brackets. a. ex: vending machine- alphabet {coin, chocolate} b. not valid: {coin, car} Trace: sequence of symbols recording the events in which the process has engaged in within a given time. The trace is enclosed within angle brackets. c. Vending machine:

Nondeterminism

In a concurrent program, two or more processes compete for the same resource. The resolution of this dilemma is not always deterministic. The unpredictable arrival order of messages creates a nondeterministic state (2).

Ex: A change machine can give change for a dollar in many different ways: four quarters, ten dimes, 100 pennies. The type of change given is not dependent on the type of change machine, but rather by some arbitrary or nondeterministic fashion.

Ex2: A passenger waiting for the bus to take him to London. The A, B, D, and F lines all go to London. The passenger can take any f these lines. Which line he gets on is only dependent upon which bus arrives first.

Why nondeterminism? Programmers use nondeterminism to exclude the events that don’t effect the outcome as a technique to simplify the problem. In the case of the change machine, only the sum, not the combination of coins matters. By reducing the number of variables, nondeterminism helps maintain a high level of abstraction when describing complicated systems.

Problems with nondeterminism Although nondeterminism can greatly reduce the complexity of problems, they also introduce their other issues. In a deterministic program, the answer will always be the same given the same inputs. In a nondeterministic program, the same inputs can yield different answers on different cycles or machines. This characteristic makes it difficult to check whether the program works.

CSP and nondeterminism

CSP introduces the notation Π to signify a process which “behaves either like P or like Q, where the selection between them is arbitrarily, without the knowledge of the external environment (1).”

Ex: During lunch, you can choose between an apple or an orange. The choice can be mathematically expressed as: orange Π apple, where the choice between the two is based on a unaccounted external factor.

Algebraic laws governing nondeterministic choices are simple.

  • Idempotenence: A choice between P and P is empty P Π Q = P
  • Symmetry: P Π Q= Q Π P The order does not influence the choice
  • Associative: P Π (Q Π R) = (P Π Q) Π R The choice between three options can be divided into two successive single choices.
  • Distributive: x → (P Π Q) = (x → P) Π (x → Q) Going from a defined path x to a choice between path P and Q, is the same as choosing between the options of going from path x to P or from path x to Q.

Fairness

In some theories, nondeterminism is obliged to be fair, in the sense that an event that infinitely often may happen eventually must happen (though there is no limit to how long it may be delayed). In Hoare’s theory, the concept of fairness doesn’t exist:

“Because we observe only finite traces of the behaviour of a process, if an event can be postponed indefinitely, we can never tell whether it is going to happen or not. If we want to insist that the event shall happen eventually, we must state that there is a number n such that every trace longer than n contains that event. Then the process must be designed explicitly to satisfy this constraint. For example, in the process P0 defined below, then event a must always occur within n steps of its previous occurrence.”

-Learning CSP

If fairness is required for the program, it must be considered and accounted for separately.

Shared Resources

Laws for reasoning about sequential processes derives from the fact that each variable is updated by one process (learning CSP). If storage is shared, only one process can change the variable. The potential for data corruption makes common variables and communication amongst processes difficult to implement.

Deadlock

Deadlock is the permanent blocking of a set of processes. It is a common problem in concurrency and arises from the conflicting needs of processes for similar resources or when communicating with each other.

Example of deadlock: Intersection of cars(3). The shared resources can be thought of as the lanes. Each car shares the four lanes. The process is the car. Deadlock occurs when each process holds one resource and requests the other. While one car can decide to switch lanes, no car can agree on the proper action to take. As in traffic, deadlock in computer science slows or completely halts a program.

Classical illustration of deadlock

There is a group of five philosophers who do nothing but eat and think all day. The philosophers sit around a round table with a bowl of noodles in the middle. As philosophers get paid less than computer scientists, they can afford only five single chopsticks, which are placed on each side of the philosopher. To eat the noodle, the philosopher needs both chopsticks. The philosopher first picks up the chopstick from his left, and then his right if it is not being used.

Deadlock arrives when all philosophers want to eat at exactly the same time. All philosophers pick up the chopstick to their left. However, none of the philosophers can eat because another philosopher is currently using the other chopstick.

Events that lead to Deadlock

There are several combinations of events can cause deadlock

  1. Mutual exclusion: Only one process can use a resource at a time
  2. Hold- and- wait: A process holds onto its resource until the next resource its needs becomes available
  3. No preemption: No process can be forced to give up its resources
  4. Circular wait: closed chain of processes where each process holds the resource the next process needs to function.

While these situations can lead to deadlock, there are precautions programmers can take to prevent their occurrence.

  1. Mutual exclusion: Restrict the way in which resources can be requested.
  2. Hold- and- wait: Require all processes to provide information about the resources they will need in advance. Use algorithms to insure that all resources are available to the process before it attempts to acquire them.
  3. Circular wait: Establish a priority system that requires processes to request resources and process them in that order, such that a higher priority process will always have access to the resource first. This solution can lead to starvation.

Eliminating the possibility of a deadlock is better than dealing the deadlock during execution. However there will may arise arrive unique combination of situations that lead to deadlock. There are methods of resolving a deadlock when it’s detected, but these solutions are not efficient and resolve in lost data (4).

  1. Preempt the resource from a process. The preempt process can be resumed at a later time.
  2. Return to a point where the process did not need the acquired resource causing the deadlock.
  3. Systematic killing of jobs until deadlock is resolved.

CSP and deadlock solution

In order to prevent data corruption, Hoare purposed the concept of a critical area. Processes cross the critical area to gain access to the shared data. Before entry to the critical area, all other processes must verify and update the value of the shared variable. Upon exit, the processes must again verify that all processes have the same value.

Another technique to maintain data integrity is through the use of mutual exclusion semaphore or a mutex. A mutex is a specific subclass of a semaphore that only allows one process to access the variable at once. A semaphore is a restricted access variable that serves as the classic solution to preventing race hazards in concurrency. Other processes attempting to access the mutex are blocked and must wait until the current process releases the mutex. When the mutex is released, only one of the waiting processes will gain access to the variable, and all others continue to wait.

In the early 1970s, Hoare developed a concept known as a monitor based on the concept of the mutex. According to a tutorial on CSP in the Java programming language written by IBM:

“A monitor is a body of code whose access is guarded by a mutex. Any process wishing to execute this code must acquire the associated mutex at the top of the code block and release it at the bottom. Because only one thread can own a mutex at a given time, this effectively ensures that only the owing thread can execute a monitor block of code.”

Monitors can help prevent data corruption and deadlocks (5)

Possible Solutions to Philosopher Problem

A physical representation of the solution to the deadlock problem can be visualized as the footman. The behavior of the footman allows him to sit only four philosophers at the table simultaneously.

The metaphor of the dining philosophers was thought by the well known computer scientist, Edsger Dijkstra. Carel S. Scholten discovered the footman solution.

Infinite Overtaking

This problem arises when priority is assigned to programs. Some program always takes precedence at the expense of other programs that are delayed forever.

Ex: You are waiting to be seated at a restaurant. You are next in line, and just about to be shown your table when a famous actor walks in. The restaurant, mindful of good publicity, seats the famous actor first. When the next table becomes available, the waiter turns to you, but then sees a famous singer walk in. Again, the waiter seats the singer before you. The weighting of resources leaves you at a disadvantage. If this cycle continues, you could be delayed forever, or at least for an unacceptable period of time.

Overtaking Solution

The task of deciding how to allocate resources to waiting processes is called scheduling. Scheduling is split into two events, which Hoare terms the please and the thankyou:

  1. Please- processes requesting the resource
  2. Thankyou- the allocation of the resource to processes.

The time between the request and granting of the resource is the waiting period. In CSP, there are several techniques that prevent infinite waiting times.

  1. Limiting resource use and increasing availability of resource.
  2. First in first out (FIFO)- allocate resource to the process that has waited the longest.
  3. Bakery algorithm (A more technical explanation of the scheduling algorithm can be found in the reference (6))

Limitations of CSP

In determininistic programs, the result will be the same if the environment is constant. Because concurrency is based on non-determinisim, the environment does not affect the program. Given the paths chosen, the program can run several times and receive different result. To insure the accuracy of concurrent programs, programmers must be able to consider the execution of their program on a holistic level.

However, despite the formal methods that Hoare introduced, there still lacks any proof method to verify correct programs. CSP can only catch problems it knows exists, not unknown problems. While commercial applications based on CSP, such as ConAn, can detect the presence of errors, it can’t detect their absence. While CSP gives you the tools to write a program that can avoid the common concurrency errors, the proof of a correct program remains an unresolved area in CSP.

Future of CSP

CSP has great potential in biology and chemistry to model complex systems in nature. It has not been widely used in industry because of the many existing logical problems facing the industry. At the conference for the 25th anniversary for the development of CSP, Hoare noted that despite the many research projects funded by Microsoft, Bill Gates ignores the issue of when Microsoft will be able to commercialize the work on CSP (7).

Hoare reminds his audience that the area of dynamic procedures still requires much more research. Currently, the computer science community is stuck in the paradigm of sequential thought. With the foundation in formal methods of concurrency established by Hoare, the scientific community is primed to being the next revolution in parallel programming.

References

  1. Hoare, C.A.R. Learning CSP. June 21, 2004.
  2. Haghighi, Hassan and Mirian-Hosseinabadi, Seyyed H. Nondeterminism in Formal Development of Concurrent Programs: A Constructive Approach
  3. Concurrency: Deadlock and Starvation. Presentation Obtained from engr.smu.edu/~kocan/7343/fall05/slides/Chapter06.ppt
  4. Rinard, Martin C. Operating Systems Lecture Notes
  5. Abhijit Belapurkar. CSP for Java Programmers, Part 1
  6. Carnegie Melon. Bakery Algorithm
  7. Numerico, Teresa an Bowen, Jonathon. 25 Years of CSP

Modular software design

Mike's Notes

A good, clear explanation of modular system design by Chris Loy.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

25/01/2026

Modular software design

By: Chris Loy
Chris Loy: 24/01/2025

Hey, I'm Chris. Nice to meet you!

I spend my professional life writing code, training machine learning models, building software products and running tech teams. I'm a startup founder with a successful exit, and in my career I've been CTO, a developer and a data scientist. I've worked at companies big and small, mentored junior engineers and data scientists from across Europe, and served as an advisor for some companies. Throughout my career I have been lucky enough to work with and hire some amazingly smart people.

This is my website, where I write about tech, data and AI, as well as some of my other interests and hobbies. Those include music and photography, and I also use this site to document the books I read..

Whenever people ask me about my philosophy for building software, top of my list is always to say that I am a proponent of modular design. To explain what I mean by that, it is first necessary to understand a few of the fundamental theories that underpin how I view software engineering as a discipline, and then we can explore how those come together in a philosophy of modularity.

Systems

Software engineering is a discipline for the design and implementation of complex systems of interacting elements. If a program is intended to serve a single purpose by completing just one task, that task can be broken down into smaller tasks, which can themselves be broken down further and further.

The result of conceptually atomising monolithic operations is a network of interdependent operations that comprise the wider system. The boundaries of this system are wide and varied - how data is written and read from hardware devices, communication of information between geographically separated networks, even the knowledge and opinions of humans interacting with websites or smartphone apps. Whatever we are building, our control extends only partway through the network.

Systems thinking is the embracing of the vastness and complexity of all the moving parts that influence the operation of software. The challenges we face therefore come from the limits of our own capacity for comprehension.

Abstraction

To address this complexity, the primary philosophical tool in the software engineer’s belt is abstraction. To abstract something is to hide its complexity by defining only the way that it interacts with the world around it, and to deliberately behave in a way that ignores the inner workings of the thing.

This is the fundamental thought process in software development, first articulated by Dijkstra in his essay “The Humble Programmer”. The central thesis of that essay, written in the 1970s before the invention of the microprocessor, was that as programmers we are developing systems too complex to hold fully within our mind all at once. At the time, this was a unique and forward-thinking insight - today it is obvious.

Abstraction teaches us that software engineering is a philosophical discipline - one in which our goal is to enhance our ability to reason about complex systems by effectively abstracting away complexities that lie outside our immediate sphere of interest. Components that are behind or within the components we directly interact with are ignored - only the immediate effect on us is relevant.

Encapsulation

To make this kind of abstraction possible, it is necessary that components within the system encapsulate their complexity such that others can abstract it away when interacting with them.

This concept is often talked about within the domain of object-oriented design - a discipline that is perhaps less fashionable than it once was, but still underpins much of the fundamental way in which software is best built. The core idea is that a component should encapsulate its functionality and only present what it does to the outside world, not how it does it. It is not necessary to understand what happens to the engine of a car when you depress the accelerator pedal - only to know that it goes faster.

In normal language, we would call the surface of encapsulated functionality an interface, but our industry loves three letter acronyms, and so we universally tend to use the clunky term Application Programming Interface for this, or API for short.

Recursion

Recursion is a simple-to-explain, difficult-to-grasp context from mathematics that is all over software design. The simple explanation is that it is just the concept of a system in which components can be self-referential within their category. To give an example, I have two parents, and each of them had two parents, and so on. The “and so on” in this sentence is the recursion. This one very simple relationship belies a hugely complex tree of connections - my family tree, in this case.

Through this lens, there are no limits to encapsulation, where each layer of abstraction can be nested within arbitrary other layers of abstraction. Components encapsulate components, recursively. A component has many components within it, each of which has many more. And so on.

The ability to zoom into the right layer of abstraction within this tree of complexity is how we accomplish the task of writing software. By well defining interfaces around components, by abstracting the details of how they work and instead just understanding what they do, and by navigating through a recursive tree of components, we are able to reason about the behaviour of our system at all levels of abstraction.

Modularity

What then, is modular software design? Well, it is an acceptance of the above philosophy, and an embracing of the implications, specifically in thinking about how systems evolve over time. For me, this fundamentally comes down to designing systems such that you maximise your ability to effect change through adding, moving or replacing components, rather than modifying existing ones. This motivation comes from the hard-earned experience that modifying working software is hard, but replacing or adding software can be easy if your setup is optimised for it.

By thinking of systems as networks of interconnected and nested components, and adopting a strategy of ensuring all of those components have well defined interfaces at each layer of abstraction, we build software that is flexible, resilient and easy to reason about.

The Software Engineer’s Guidebook: a recap

Mike's Notes

An excellent article by Gergely Orosz on publishing a software book. Ajabbi will eventually need to publish some books for users (I won't be the author), so I'm learning from his experience.

The original article has many links.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > The Pragmatic Engineer
  • Home > Handbook > 

Last Updated

10/12/2025

The Software Engineer’s Guidebook: a recap

By: Gergely Orosz
The Pragmatic Engineer: 12/11/2025

Writing The Pragmatic Engineer. Previously at Uber, Skype, Microsoft. Author of The Software Engineer's Guidebook.

Reflections on publishing The Software Engineer’s Guidebook two years ago, which has sold around 40,000 copies. Also: an unexpected trip to Mongolia to visit the startup which translated it

Two years ago almost to the day, I published The Software Engineer’s Guidebook. Originally, it came out in paperback, then as an ebook and an audiobook. I’m happy to share that it is now available as a hardcover, and is also on the O’Reilly platform.

Hardcover edition: Durable and could make a nice gift for the holidays. You can get it here

Today, I’d like to draw back the curtain on the process of writing a book as a techie:

  1. Pitching to publishers. And why I ended up breaking up with a publisher.
  2. Self-publishing. The tools I used for writing and the platforms I published on.
  3. Traveling to Mongolia to meet the startup which translated the book. A 30-person startup called Nasha Tech translated the book for the benefit of their company and the Mongolian tech ecosystem.
  4. How much did my book earn? $611,911 in two years from sales totalling 40,000 copies, to date. We need more good books in tech, so I hope that sharing these numbers inspires other techies to write them.
  5. Learnings from writing my book. It’s hard to judge a book’s impact, but good books stay valuable for longer – that’s why they’re hard to write.

1. Pitching to publishers

In late 2019, I was an engineering manager at Uber, the ridesharing app. For the first time in my career, I was a manager of managers: suddenly, I had “skip level” software engineers, and it was here that the inspiration came to write a book that provides some advice and observations for these tech professionals.

During a 1:1 catchup with a new joiner skip-level engineer, they asked about getting up to speed in the workplace faster. They were at the Software Engineer 2 (L4), and wanted to figure out how to get to the Senior engineer level (L5A at Uber). I thought it would’ve been nice to give them a book with a bunch of pointers about what it takes to become an effective software engineer in this environment.

With that inspiration to write a book about professional growth at large tech companies and startups, I looked for publishers who could help make it a reality. I pitched my book to 3 publishers behind the highest quality tech books in the industry – O’Reilly, The Pragmatic Bookshelf, and Manning. O’Reilly and The Pragmatic Bookshelf passed, but Manning said yes.

Mental model of publishers in 2025. I pitched my book to the 3 most reputable tech publishers

I learned a lot by working with a publisher: the process of preparing a book to be ready for sale is much more involved than I’d assumed! I even came to appreciate why publishers may keep up to 85-90% of sales revenue, with authors typically getting 7-15% of royalties from print sales.

The chart below sets out the publication process at a typical tech book publisher, from the author pitching their idea for a book, all the way through to its launch:

Steps to publish a book with a publisher

Unfortunately, after three months with Manning and one editorial review, it was clear that the publisher and my book weren’t a good match. At the time, Manning had a very opinionated template for creating books which I felt pushed my own in a direction I wasn’t happy with: I felt the book would be dumbed down, and that following some of the guidance would weaken it. Also, I was less comfortable with some of the conditions and feared my hands could be tied if I wanted to share draft material online,. Also, I would not be able to choose the book title. So, we parted ways. You live and learn!

I shared more details about my experience of working with publishers in this article, including the financials of choosing a publisher as a writer.

2. Self-publishing

The biggest downside of not having a publisher is the lack of deadline pressure. Below is the rough structure I used for writing my book:

  1. Getting the idea and the motivation
  2. Rough outline
  3. Procrastination about the topic
  4. Table of contents
  5. Writing the draft – the longest part of all
  6. Copyediting
  7. Content feedback
  8. Final copyedit
  9. More procrastination about the final draft
  10. Production layout editing: getting the book ready for print
  11. Cover design
  12. Test printing
  13. Launch planning
  14. Launch!

Weighted table of contents

One very useful thing I took from Manning’s process is to start the book with a table of contents, where you estimate the rough number of pages one section will be about. This is helpful because the published version should not be too long or too short, so this helps set its scope and how topics should be tackled.

Here is an example of the weighted table of contents for one chapter:

My weighted table of contents

This exercise resembled estimating the size of a piece of work during the planning for a software project, and provided a sense of what the longer and shorter parts of the book would be.

Write, write, write

The biggest part of writing a book is… writing it. I tried to have some regular cadence of writing, but struggled to get into one. I ended up making progress in bursts, and shared drafts on social media – like this one on healthy and unhealthy teams. This generated more ideas and I continued writing.

It’s easy to get distracted and procrastinate. A 400-page book is too large a project to take on in one go, and sometimes parts of the book change shape: an estimated 4 pages on something can turn into 20 pages a week later. It was like treading water: not making much progress with the book as a whole and being distracted by interesting topics.

Starting The Pragmatic Engineer Newsletter to finish the book

Two years into writing the book, its completion was forever 6 months away. I realized my writing process, with no publisher involved, was inefficient and unfocused.

In August 2021, I started The Pragmatic Engineer Newsletter with the hope that writing a weekly newsletter would speed up completion of the book. My thinking was to send out a draft version of a part of the book as a newsletter every few weeks.

The idea was sound, but I quickly realized that online newsletter issues can be a lot more in-depth than a chapter in a book can be, due to the issue of space constraints. Also, newsletters are timely by nature (covering what’s happening, right now), whereas a book often covers ideas that remain relevant for years.

I am thankful to have started The Pragmatic Engineer Newsletter, but doing so didn’t hasten the publication of The Software Engineer’s Guidebook. It actually delayed it by another two years.

Tools I used for self-publishing

There’s many tools available for writing a book, not including new AI tools for generating ideas – or even doing the writing in certain cases. Here’s the tools I chose:

  • Writing process: Google Docs and Craft. Most of my drafts were in Google Docs, and all my ideas and notes went into Craft.
  • Creating an ebook: Vellum. A one-off purchase, which helps generate e-book and print versions. I didn’t use it for print generation, as the software seems to be optimized for fiction.
  • Print layout: Overleaf. The PDF layout for print took significant effort, as I wanted to have an index in the end of the book. I ended up hiring a LateX expert who helped create a nice print layout, which would have been challenging for me to do, and time-consuming to learn.
  • Reader feedback: Betabooks. I wasn’t entirely satisfied as it’s pretty janky to use. In hindsight, sharing drafts in Google Docs and letting readers add comments might have been equally effective.
  • ISBN numbers: when self publishing, you need to purchase your own ISBN and these depend on your region. ISBN Services is a popular choice for the US. I’m residing in the Netherlands, so used the Dutch Mijn ISBN.
  • Book cover design: Canva. Lots of templates to work with, and it’s easy to work with the exact size requirements for print covers, as well. The cover you see today is my wife’s work.

Publishing platforms

I publish my books on these platforms:

  • Print book: Amazon Kindle Direct Publishing (KDP) and Ingram Spark. Amazon covers most countries – but not all; notable gaps include India. Ingram Spark allows libraries and bookshops to order the book. If your title is not expected to be highly popular, Amazon KDP will probably be more than sufficient for print distribution.
  • Ebook: Gumroad (to sell the ebook DRM-free), Amazon KDP, Kobo Store, Google Play, and PublishDrive. Publishdrive is a neat service that publishes ebooks and audiobooks to all large and small platforms. In hindsight, I’d probably just use them to publish to all major platforms.
  • Audiobook: Voices (formerly: Findaway Voices). For some strange reason, Amazon’s audiobook platform (ACX) only allows residents of the US, Canada, UK, and Ireland, to publish on it. Being a resident in the Netherlands, I had to go with a third-party platform to publish to Amazon. Voices used to be owned by Spotify, and has been spun out into its own company. If I published today, I’d likely just go with PublishDrive for my audiobook, as well.

There’s a long tail of ebook and audiobook platforms, and it makes sense to use an aggregator service that publishes to most, if not all of them, and which then sends a combined payout, instead of lots of small payments from each platform.

Don’t forget the launch

Going with a publisher has the benefit that they coordinate launch activities, and also list your book on their New Releases pages, which leads to added awareness. Superior publishers also reach out to potential reviewers, and are hands-on in helping with the launch.

I knew I couldn’t count on launch support, so built a landing page where I collected emails of people who wanted to know when the book was released. To incentivize this, I provided details about the book, and the table of contents.

In hindsight, this was one of the best things I did: a good chunk of sales at launch came from people who received the email that the book was ready for purchase. Here’s how the book’s website looked, back then.

Landing page for the book, pre-publication

Another approach that worked well was having a dedicated social media account for the book, where I shared drafts while working on certain chapters. I was surprised by how many reshares a page or two of the work-in-progress book got, like this one.

One of many examples of sharing a work-in-progress version of a chapter. Source: X

Still, the biggest benefit of sharing drafts was that I got nearly as much feedback from social media users as from beta readers.

Procrastination is real – deal with it

Writing “the book” I’d always wanted made me freeze at times: it was something I’d never done before, it was a large project, and I wanted to get everything right.

In the end, as with software, “done is better than perfect”. Just like when working on a big software launch, the best way to make progress is to forget about how many people might use the product, and to just focus on the next task to complete… then the next… then the next.

It was amusing to remind myself that tech products I’d worked on were used by many times more people than the book could ever hope to reach – so why procrastinate? Plus, mistakes can be fixed with ebooks, they are trivial to do with a re-publish. Of course, this isn’t possible in the same way with print books, but print-on-demand means issues can be resolved in future copies.

3. Traveling to Mongolia to meet the startup which translated my book

An unexpected highlight of publishing the book was ending up in Mongolia in June of this year, at a small-but-mighty startup called Nasha Tech. This was because the startup translated my book into the Mongolian language. Here’s what happened:

A little over a year ago, a small startup from Mongolia reached out, asking if they could translate the book. I was skeptical it would happen because the unit economics appeared pretty unfavorable. Mongolia’s population is 3.5 million; much smaller than other countries where professional publishers had offered to do a translation (Taiwan: 23M, South Korea: 51M, Germany: 84M people).

But I agreed to the initiative, and expected to hear nothing back. To my surprise, nine months later the translation was ready, and the startup printed 500 copies on the first run. They invited me to a book signing in the capital city of Ulaanbaatar, and soon I was on my way to meet the team, and to understand why a small tech company translated my book!

Japanese startup vibes in Mongolia

The startup behind the translation is called Nasha Tech; a mix of a startup and a digital agency. Founded in 2018, its main business has been agency work, mainly for companies in Japan. They are a group of 30 people, mostly software engineers.

Nasha Tech’s offices in Ulaanbaatar, Mongolia

Their offices resembled a mansion more than a typical workplace, and everyone takes their shoes off when arriving at work and switches to “office slippers”. I encountered the same vibe later at Cursor’s headquarters in San Francisco, in the US.

Nasha Tech found a niche of working for Japanese companies thanks to one of its cofounders studying in Japan, and building up connections while there. Interestingly, another cofounder later moved to Silicon Valley, and advises the company from afar.

The business builds the “Uber Eats of Mongolia”. Outside of working as an agency, Nasha Tech builds its own products. The most notable is called TokTok, the “UberEats of Mongolia”, which is the leading food delivery app in the capital city. The only difference between TokTok and other food delivery apps is scale: the local market is smaller than in some other cities. At a few thousand orders per day, it might not be worthwhile for an international player like Uber or Deliveroo to enter the market.

The TokTok app: a customer base of 800K, 500 restaurants, and 400 delivery riders

The tech stack Nasha Tech typically uses:

  • Frontend: React / Next, Vue / Nuxt, TypeScript, Electron, Tailwind, Element UI
  • Backend and API: NodeJS (Express, Hono, Deno, NestJS), Python (FastAPI, Flask), Ruby on Rails, PHP (Laravel), GraphQL, Socket, Recoil
  • Mobile: Flutter, React Native, Fastlane
  • Infra: AWS, GCP, Docker, Kubernetes, Terraform
  • AI & ML: GCP Vertex, AWS Bedrock, Elasticsearch, LangChain, Langfuse

AI tools are very much widespread, and today the team uses Cursor, GitHub Copilot, Claude Code, OpenAI Codex, and Junie by Jetbrains.

I detected very few differences between Nasha Tech and other “typical” startups I’ve visited, in terms of the vibe and tech stack. Devs working on TokTok were very passionate about how to improve the app and reduce the tech debt accumulated by prioritizing the launch. A difference for me was the language and target market: the main language in the office is, obviously, Mongolian, and the products they build like TokTok also target the Mongolian market, or the Japanese one when working with clients.

One thing I learned was that awareness about the latest tools has no borders: back in June, a dev at Nasha Tech was already telling me that Claude Code was their daily driver, even though the tool had been released for barely a month at that point!

Why translate the book into Mongolian?

Nasha Tech was the only non-book publisher to express interest in translating the book. But why did they do it?

I was told the idea came from software engineer Suuribaatar Sainjargal, who bought and enjoyed the English-language version. He suggested translating the book so that everyone at the company could read it, not only those fluent in English.

Nasha Tech actually had some in-house experience of translation. A year earlier, in 2024, the company translated Matt Mochary’s The Great CEO Within as a way to uplevel their leadership team, and to help the broader Mongolian tech ecosystem.

Also, the company’s General Manager, Batutsengel Davaa, happened to have been involved in translating more than 10 books in a previous role. He took the lead in organizing this work, and here’s how the timelines played out:

  • Professional translator: 3 months
  • Technical editor revising the draft translation: 1 month
  • Technical editing #2 by a Support Engineer in Japan: 2 months
  • Technical revision: 15 engineers at Nasha Tech revised the book, with a “divide and conquer” approach: 2 months
  • Final edit and print: 1 month

This was a real team effort. Somehow, this startup managed to produce a high-quality translation in around the same time as it took professional book publishers in my part of the world to do the same!

A secondary goal that Nasha Tech had was to advance the tech ecosystem in Mongolia. There’s understandably high demand for books in the mother tongue; I observed a number of book stands selling these books, and book fairs are also popular. The translation of my book has been selling well, where you can buy the book for 70,000 MNTs (~$19).

Book signing and the Mongolian startup scene

The book launch event was at Mongolia’s startup hub, called IT Park, which offers space for startups to operate in. I met a few working in the AI and fintech spaces – and even one startup producing comics.

Book launch event, and meeting startups inside Mongolia’s IT Park

I had the impression that the government and private sector are investing heavily in startups, and want to help more companies to become breakout success stories:

  • IT Park report: the country’s tech sector is growing ~20%, year-on-year. The combined valuation of all startups in Mongolia is at $130M, today. It’s worth remembering that location is important for startups: being in hubs like the US, UK, and India confers advantages that can be reflected in valuations.
  • Mongolian Startup Ecosystem Report 2023: the average pre-seed valuation of a startup in Mongolia is $170K, seed valuation at $330K, and Series A valuation at $870K. The numbers reflect market size; for savvy investors, this could also be an opportunity to invest early. I met a Staff Software Engineer at the book signing event who is working in Silicon Valley at Google, and invests and advises in startups in Mongolia.
  • Mongolian startup ecosystem Map: better-known startups in the country.

Two promising startups from Mongolia: Chimege (an AI+voice startup) AND Global (fintech). Thanks very much to the Nasha Tech team for translating the book – keep up the great work!

4. How much did my book earn?

There’s usually little information about the key topic of how much authors make from their books being published, beyond “not much”. Author Justin Garrison shared that his co-authored title Cloud Native Infrastructure earned $11,554 in its first year – and without three unexpected sponsorships, that amount would’ve been $3.500. Conventional wisdom states you should not write a book for money, but for the other benefits like building your status as an expert in a domain, or exploring a topic in more depth.

A notable exception to this rule is Designing Data Intensive Applications, whose author Martin Kleppman made $477,916 in royalties in the first 6 years of publication, as he shared. Martin published with O’Reilly, and the book sold 108,000 copies, generating around $4.50 per copy in royalties for the author. Still, Designing Data Intensive Applications is one of the most successful books, and Martin argues that a book’s real value lies in the value it creates:

“Writing a book is an activity that creates more value than it captures. What I mean with this is that the benefits that readers get from it are greater than the price they paid for the book. To back this up, let’s try roughly estimating the value created by my book.

It’s hard to quantify that, but let’s say that the people who applied ideas from the book avoided a bad decision that would have taken them one month of engineering time to rectify. (I’d actually love to claim that the time saving is much higher, but let’s be conservative in our estimates.) Thus, the 10,000 readers who applied the knowledge freed up an estimated 10,000 months, or 833 years, of engineering time to spend on things that are more useful than digging yourself out of a mess.

If I spend 2.5 years writing a book, and it saves other people 833 years of time in aggregate, that is over 300x leverage. If we assume an average engineering salary on the order of $100k, that’s $80m of value created. Readers have spent approximately $4m buying those 100,000 books, so the value created is about 20 times greater than the value captured. And this is based on some very conservative estimates.”

The Software Engineer’s Guidebook will probably be another exception; it has sold 40,000 copies and netted $611,911 in royalties in the two years since publishing:

Cumulative royalties for The Software Engineer’s Guidebook

Here is how revenue from different platforms adds up:

Print:

  • Amazon KDP: 29,806 copies, $470,000 in royalties ($16 per book)
  • Ingram Spark: 1,316, copies, $10,322 in royalties ($8 per book)

Ebooks:

  • Kindle: 3,909 copies, $42,992 royalties ($11 per book)
  • DRM-free ebooks: 2,713 sales, $54,963 royalties ($20 per book).
  • Other ebooks: 388 copies, $6,882 in royalties ($17 per book). 90% of sales came from iTunes, Google Play and Kobo.

Audiobook:

  • Amazon, Spotify, and other platforms: unclear how many purchases, $6,511 royalties (Audible typically pays around $1.50-3.50 per audiobook, Spotify closer to $9)
  • DRM-free ebook: 241 sales, $3,241 royalties ($13 per book)
  • I previously shared more about how I created the audiobook

Translations:

  • 5 languages, $17,000 in upfront royalty payments (South Korea: $5,000, Japan: $4,500, Germany: €3,000, Taiwan: $2,000, China: $2,000)

Total: $611,911 in royalties, circa 40,000 in copies sold (38,373 copies, plus audiobooks, plus foreign translations that don’t have exact numbers)

These are good numbers for a tech book, and it enjoyed the advantage of being published after The Pragmatic Engineer newsletter found an audience online. Thank you to everyone who purchased a copy of the book or gifted one!

It’s interesting, as someone who self-published print and audiobook versions of their title, that royalties per book sold are highest in paperback, and much lower for the ebook and the audiobook. This is because Amazon takes 70% of the purchase price of the Kindle ebook, and 75% for the audiobook, but only 40% for the print book, in marketplace fees.

Self-publishing definitely helped substantially increase the royalties generated from the book, which would be 4-8x lower if done via a publisher. At the same time, self publishing increased the amount of time and effort I needed to invest.

5. Learnings from writing my book

The impact of a book is hard to know with certainty. When I publish a newsletter article or a podcast episode, the feedback is almost immediate: I get comments, emails, and mentions about the contents for a few days – perhaps a week or two. After that, I rarely hear feedback again.

But I run into people at events and conferences who say the book helped them focus more on their career, or get a desired promotion to senior-or-above.

A lot more readers than expected find the book via recommendations or gifting. I hear stories about my book being recommended or purchased for engineers by managers, or peers, or friends – and then they felt obliged to start to read it. This kind of dynamic also exists with articles and podcast episodes, but my sense is that being given a book is a very strong nudge to invest time in the resource.

Good books stay valuable for longer – that’s why they’re hard to write. The final 18 months of writing the book mostly involved editing the existing draft. I tried to remove details that were likely to age poorly in the near to medium term future – like mentions of specific frameworks, or things that felt like short-lived fads (e.g: “web3” engineering as a category, which seems to have mostly vanished from the discourse.

Even so, I got burnt by the fast-changing nature of tech. In my last edits, I added short sections on AI, about how it’s a useful tool to learn languages with, or for getting unstuck. I gave examples of tools that were popular in 2023, and predicted they would remain relevant: ChatGPT, GitHub Copilot, and Google Bard. I figured that OpenAI would be around for at least 5 years, and that Microsoft and Google know how to name their products.

I was wrong: Google renamed Bard to Gemini four months after my book was published. In response, I removed all product mentions from an updated version of the book: who knows when the search giant will change the name again!

Amazon’s print-on-demand service is incredibly good. Amazon prints books on demand in 10+ markets, and ships these on-demand books to even more countries. Books printed this offer the highest price-per-value across all print-on-demand services I found. Amazon’s KDP is considerably more price efficient compared to the other major print-on-demand player, Ingram Spark.

One paperback copy of my book (a 413 page book) costs $8 to print with Amazon. With Ingram Spark it’s double this: $16! This is a massive difference in printing costs that is hard to ignore, and is one reason to choose Amazon’s print-on-demand service as primary distribution for print books. This explains why my royalties per book are $16 with Amazon prints, and $8 with Ingram Spark prints.

Ebook, audiobook and print sales reporting feels stuck in the 1990s. Both ebooks and audiobooks are digital products, so you’d expect it would be possible to get near-real time sales data. But the reality is that it’s not: audiobook platforms like Spotify and Audible release reports monthly (as I understand), and good luck trying to figure out which sales equate to what! This is after Audible takes 80% from sales.

Ebook reporting is similarly slow, due to sales being reported in a delayed fashion. There are so many audiobook and ebook platforms to buy on that it’s only sensible to use an aggregator like Publishdrive or Voices. This adds one more layer of abstraction and more reporting delays. I understand that print sales take months to be reported, but did not expect it to be the case with audiobooks.

Even today, I have no idea how to find out how many people have listened to the audiobook, and by now I would have hoped for better reporting. It shows that if there are few suppliers in a segment (like audiobook publishers, who use these reporting tools) and not much competition: companies can get away with poor tooling.

Print reporting is perhaps even more unusable. Ingram Spark is one of the biggest print-on-demand providers - but it’s not possible to get a report about a sales period longer then a year. The cherry on the cake is how if you query a period longer than 100 days, they can only email these reports:

Ingram Spark’s reporting interface and functionality feels stuck 10+ years in the past. Responsive web applications, anyone?

This is a portal that has had no usability testing — and customer seem to put up with it:

Ingram Spark: instead of implementing queuing of reports, they just push the error onto the user. A hostile user experience in 2025

Amazon has an unhealthy monopoly on the audiobook and ebook sectors. Amazon generated more revenue from books sold on its site than I did, as a self-published author:

  • 75% of revenue for all audiobooks sold via Audible
  • 70% for all Kindle ebooks
  • 40% for all print books as Amazon marketplace fees

That Amazon has a take rate of 75% for audiobooks and 70% for Kindle ebooks (those priced above $10) and still controls most of the market, makes this segment look like a monopoly. I offer my ebooks and audiobooks as DRM-free versions, and am happy to see more customers choose these options over the Kindle or Audible ones. Still, market forces alone don’t feel strong enough to challenge Amazon’s dubious pricing and practices. I wrote more about Amazon’s monopolistic audiobook practices.

Looking back on the experience of writing my book, it was worth it for the thinking and organization that it forced on me. It has been an unusually long professional project that stretched across four years and I’ve learnt a lot from the process: it forced me to think deeply about topics like the importance of software architecture, and figuring out how a business works, as a Staff+ engineer. It forced me to rewrite and refine my ideas multiple times, and with each rewrite came fresh ideas and a clearer understanding of the subject. This is what really matters for software engineers to progress professionally in the industry, I believe.

Ultimately, I hope the book generates more “wealth” by helping out devs in a career rut, or who are seeking inspiration to get stronger as engineers. Obviously, commercial success is nice – and I shared those numbers in the spirit of transparency because I believe in the value of detailed, in-depth, and thoroughly researched and written information. Every anecdote helps dispel the myth that books cannot be decent earners for their authors.

If you’re in the process of writing a book, why not get in touch about doing a guest post in this publication? Personally, I’ve found guest posts tend to be a good fit for engineers midway through writing a book!

Review Standish Group – CHAOS 2020: Beyond Infinity

Mike's Notes

I have been researching and reviewing the material referenced by Roger Sessions. This is about the Standish Group.

There is now a collection of Standish reference material in the library as part of the Roger Sessions collection.

Resources

References

  • Standish Group – CHAOS Report 2020

Repository

  • Home > Ajabbi Research > Library > Authors > Roger Sessions
  • Home > Handbook > 

Last Updated

01/06/2025

Review Standish Group – CHAOS 2020: Beyond Infinity

By: Henny Portman
Henny Portman's Blog: 06/01/2021

A few weeks ago, I received the latest report from the Standish Group – CHAOS 2020: Beyond Infinity – written by Jim Johnson. Every two years the Standish Group publish a new CHAOS Report.

These reports include classic CHAOS data in different forms with many charts. Most of the charts come from the CHAOS database of over 50,000 in-depth project profiles of the previous 5 years. You have probably seen some of those yellow-red-green charts showing e.g., challenged, failed and successful project percentages. 

The book contains ten sections and an epilogue:

Section I:

Factors of Success describes the three factors (good sponsor, good team and good place) the Standish Group has determined most seriously affect the outcome of a software project. Specific attention has been given how poor decision latency and emotional maturity level affect outcomes and the success ladder benchmark.

Section II:

Classic CHAOS provides the familiar charts and information generally found in CHAOS reports. E.g., resolution by traditional measurement, modern measurements, pure measurements and “Bull’s Eye” measurements.

Section III:

Type and styles of projects breaks down project resolution by measurement types and styles of delivery method.

In the next three sections we get an overview of the principles for the good sponsor, the good team and the good place. Each principle is explained in detail, including the required skills to improve the principle and a related chart showing the resolution of all software projects due to poorly skilled, moderately skilled, skilled and very skilled.

Section IV:

The Good Sponsor discusses the skills needed to be a good sponsor. The good sponsor is the soul of the project. The sponsor breathes life into a project, and without the sponsor there is no project. Improving the skills of the project sponsor is the number-one factor of success – and also the easiest to improve upon, since each project has only one. Principles for a good sponsor are: 

  • The Decision Latency principle
  • The Vision Principle
  • The Work Smart Principle
  • The Daydream Principle
  • The Influence Principle 
  • The Passionate Principle
  • The People Principle
  • The Tension Principle 
  • The Torque Principle
  • The Progress Principle.

Section V:

The Good Team discusses the skills involved in being a good team. The good team is the project’s workhorse. They do the heavy lifting. The sponsor breathes life into the project, but the team takes that breath and uses it to create a viable product that the organization can use and from which it derives value. Since we recommend small teams, this is the second easiest area to improve. Principles for a good team are: 

  • The Influential Principle
  • The Mindfulness Principle
  • The Five Deadly Sins Principle
  • The Problem-Solver Principle
  • The Communication Principle
  • The Acceptance Principle
  • The Respectfulness Principle
  • The Confrontationist Principle
  • The Civility Principle
  • The Driven Principle.

Section VI:

The Good Place covers what’s needed to provide a good place for projects to thrive. The good place is where the sponsor and team work to create the product. It’s made up of the people who support both sponsor and team. These people can be helpful or destructive. It’s imperative that the organization work to improve their skills if a project is to succeed. This area is the hardest to mitigate, since each project is touched by so many people. Principles for a good place are: 

  • The Decision Latency Principle
  • The Emotional Maturity Principle
  • The Communication Principle
  • The User Involvement Principle
  • The Five Deadly Sins Principle
  • The Negotiation Principle
  • The Competency Principle
  • The Optimization Principle
  • The Rapid Execution Principle
  • The Enterprise Architecture Principle.

Section VII:

Overview of the CHAOS Database explains the process of creating project cases and adjudicating them for inclusion in the CHAOS database.

Section VIII:

New Resolution Benchmark offers an overview of this new benchmark, which will replace the original in the CHAOS database. The Project Resolution Benchmark is a self-service instrument that uses a three-step method to help benchmark your organization against similar organizations on the basis of size, industry, project mix, types, and capability.

Section IX:

The Dutch Connection describes and celebrates the contributions made by our colleagues in the Netherlands and Belgium and their effect on our research.

Section X:

Myths and Illusions debunks some typical beliefs about “project improvement.” By using the data points from the database. The busted myths are:

  • Successful projects have a highly skilled project manager
  • Project management tools help project success
  • All projects must have clear business objectives
  • Incomplete requirements cause challenged and failed projects.

Epilogue

The Epilogue takes a look at 60 years of software development. The Standish Group has come up with four distinct evolutionary periods of developing software. The first period, which ran roughly from 1960 to 1980, is called “the Wild West”. The Waterfall Period ran from 1980 to about 2000. The Agile Period started around the year 2000 – and their prediction is that it will end shortly. They are now seeing the beginning of what they call the Infinite Flow Period, and they imagine that the Flow Period will last at least 20 years. In the Flow Period, there will be no project budgets, project plans, project managers, or Scrum masters. There will be a budget for the pipeline, which is a pure direct cost of the output. There will also be a cost to manage the pipeline, which will reduce the current project overhead cost by as much as 90%. This will be accomplished by reducing and eliminating most of the current project management activities. Functional description of work will come into the pipeline and out of the pipeline fully usable. Change will happen continuously, but in small increments that will keep everything current, useful, and more acceptable to users, rather than startling them with a “big bang boom” result (in a next blog I will dive into some details of the Flow method).

Conclusion:

CHAOS stands for the Comprehensive Human Appraisal for Originating Software. It’s all about the human factor. If you are looking for areas of improvement of your organizational project management skills (good sponsor, good team and good place), this guide gives a great overview where you could get the highest benefits from your investments. It gives excellent insights in root causes for project failure or success.

A pity this is the last CHAOS report (there will be an updated version in 2021, but that will not be a completely new CHAOS report). Given that The Standish Group are recommending you move to Flow, they state that there is no need for them to continue to research software projects. I would say not all projects are software projects, why not collect datapoints from non-software projects and start building a database and analyze the impact of the good sponsor, the good team and the good place for these projects too.

To order CHAOS 2020: Beyond Infinity