My 8 Favorite Quotes from Clean Agile

I recently finished Clean Agile by Robert C. Martin and wanted to highlight my favorite quotes from it.

The author is one of the founders of Agile Software Development which took off in the early 2000s. Since then Agile has gained a lot of popularity, but, according to the author, it has mutated quite a bit over the years as adopters add their own flair to it. The book is an attempt to reassert Agile’s original intent; if you really want to understand the motives behind it, Robert C. Martin has a short video explaining it.

The joy for me in reading the book came from Robert’s clear experience in the field and his anecdotes which I relate to so much. The book highlights several things that frustrate me in my current career and I appreciate the honesty and experience of the author. Its a great read for any software engineer and I highly recommend it.

Clean Agile is a treasure trove of great quotes about life as a software engineer and principles that can guide us to being better engineers. Below are my favorite 8 ones.

Physics

Physics constrains all projects to obey an unassailable trade-off called the Iron Cross of project management. Good, fast, cheap, done: Pick any three you like. You can’t have the fourth.

I like how brain dead simple this framework is for picking how to prioritize what to work on in a project. Robert goes one step further and mentions that the Iron Cross is actually a weighted function of the trade offs. I feel like this can be good language to use when working with product and business partners to explain the limits of what can be delivered or when it can be delivered.

The Date

What is the first thing you know about a project? Before you know the name of the project or any of the requirements, there is one piece of data that precedes all others. The Date, of course. And once The Date is chosen, The Date is frozen. There’s no point in trying to negotiate The Date because The Date was chosen for good business reasons. If The Date is September, it’s because there’s a trade show in September, or there’s a shareholders’ meeting in September, or our funding runs out in September. Whatever the reason, it’s a good business reason, and it’s not going to change just because some developers think they might not be able to make it.

This part had me falling out of my chair laughing. I have been in this exact conversation dozens of times. The day after I read it, I was talking to a co-worker who that week was having a “The Date” discussion. The obsession with picking target dates early in a project is ubiquitous, and to have it summarized so succinctly in an allegory was genius.

This excerpt sounds like the author might think setting a hard date is just flat out wrong, but the book ends up taking a more nuanced stance; business may in fact need to stick to the date (trade show, movie release date, etc.), but we have to acknowledge that other things need to budge to accommodate that. As software engineers we have a duty to not cut quality so the remaining thing to cut is features. This is a nice guiding principle. It should lead us away from crunch times and from producing crap that has to be rebuilt from scratch later.

Destroy Hope

This loss of hope is a major goal of Agile. We practice Agile in order to destroy hope before that hope can kill the project.

I used to think the point of Agile was to be faster, but this book argues the point is to fail sooner. The author describes a time when, early in a project, they discovered they needed at least twice as much time to finish requirements. They told this to their business partners and were met with a standing ovation. That was probably the only time that has ever happened, but I can see the value in wiping away unfounded hope that things are going to land smoothly and on time early on.

I have had experiences at work where we went to leaders early on in a project and told them the same bad news and I got a positive reaction. No one wanted to rush and launch a poor quality project and burn out the engineering team. Delivering the message early gave us time to reset expectations with business partners. I think management of expectations is a huge component in successful large projects and Robert expertly calls it out with this quote.

Changes

We developers should celebrate change because that’s why we are here. Changing requirements is the name of the whole game. Those changes are the justification for our careers and our salaries. Our jobs depend on our ability to accept and engineer changing requirements and to make those changes relatively inexpensive.

The author strikes a nice balance between taking the side of software engineers and challenging them. Robert often advocates in his books that software should be soft (easy to change) and that it is our job to figure out how to adapt to changing requirements. I agree with the sentiment and appreciate the challenge.

SWE Bill of Rights

You have the right to produce high-quality work at all times.

This is taken from a larger “software engineer” bill of rights. Its great and I intend to print it out and hang it up at work. This one is my favorite. It reminds us that, in a typical four-box, software engineers are the only participants equipped to give a proper engineering estimate. It shouldn’t be the cheapest, crappiest one possible, because that one is going to be hard to change later and is not going to meet customers’ quality expectations. We should size the amount of time it will take to (reasonably) refactor a project in addition to the base feature requirements. In this way we can continue to keep our projects healthy and easy to maintain.

Overtime

Working overtime is not a way to show your dedication to your employer. What it shows is that you are a bad planner, that you agree to deadlines which you shouldn’t agree, that you make promises you shouldn’t make, that you are a manipulable laborer and not a professional.

Software engineers live in a crunch culture where putting in huge hours before a deadline is greatly rewarded, even though it produces poor results. I see a lot of folks that are newer to industry who are willing to participate in this. Maybe its because they are new and they want to prove themselves to leaders. Maybe its because they are fresh out of college and all-nighters got them through their program and they expect it to continue to carry them.

In any case, it leads to poor software quality and it burns out engineers. Overtime it is caused by bad estimating but also leads to more bad estimating in the future (we got in done in time last time right?).

Software Engineering is Unique

Why do we need a special technique for this? Because software is unique. There are very few tasks like it. The cost/benefit and the risk/reward trade-offs in software are different from just about every other kind of work.

The author puts forth the idea that no other product is like software and no other industry is like software engineering. This is a new idea to me and I am still wrapping my head around it. Its hard for me because my only experience outside this industry is flipping burgers in high school and going to college.

The author uses this claim to say that the strategy and techniques of Agile development are exclusive of every other industry which is pretty convenient; it lets him ignore prior work in other fields. It also restricts the breadth of Agile’s impact since it only applies to the software industry.

Tech Debt

The order is to simply focus on the highest-priority item in the backlog and get it done as fast as possible - one highest-priority item after another. This approach results in a long sequence of iterative tactical work and accumulation of technical debt.

Beside killing hope (mentioned above) another benefit of Agile is that it is supposed to help engineers work on the highest impact work. If 80% of the value is going to come from the top 20% of the feature requests, this leads to huge savings for everyone. But, if we take this approach to also mean do the absolute minimum to satisfy that 20% of feature requests, we will put ourselves in a bad spot. If we interpret that to mean, we won’t test the code, we will do the hackiest, easiest thing, etc. we will have a high output of very low quality software. Following this quote, the author argues that we need to bake in the refactoring and design work in to that 20% of feature requests in order to make things maintainable.