I read it, so you don’t have to: The Nature of Software Development by Ron Jeffries
- A book written by a legend in the software engineering field.
- Very short and straight to the point — will take you ~2 hours to read.
- Best read when you have some software engineering experience, as you will be able to relate better, however still recommended for non-technical people or even students.
- Highly recommended to anyone who wants to know how to manage teams that build high-quality software systems.
- Re the actual content summary, see the summary of Chapter 1.
- Extremely catchy and edgy metaphors/aphorisms.
- Chapter organisation can be improved though.
Table of Contents
- Why read it?
- Who should read it?
- When to read it?
- Chapter by chapter summary
- Part 1: The Circle of Value
- Chapter 1: The Search for Value
- Chapter 2: Value is What We Want
- Chapter 3: Guiding Goes Better “Feature by Feature”
- Chapter 4: Organizing by Feature
- Chapter 5: Planning Feature by Feature
- Chapter 6: Building the Product, Feature by Feature
- Chapter 7: Build Features and Foundations in Parallel
- Chapter 8: Bug Free and Well Designed
- Chapter 9: Full Circle
- Part 2: Notes and Essays
- Chapter 10: Value — What Is It?
- Chapter 11: Value — How Can We Measure It?
- Chapter 12: Of Course It’s Hard!
- Chapter 13: Not That Simple
- Chapter 14: Creating Teams That Thrive
- Chapter 15: The “Five-Card Method” for Initial Forecasting
- Chapter 16: Managing Natural Software Development
- Chapter 17: Whip the Ponies Harder
- Chapter 18: To Speed Up, Build with Skill
- Chapter 19: Refactoring
- Chapter 20: Agile Methods
- Chapter 21: Scaling Agile
- What Did I Like About The Book?
- What Can Be Improved?
Why read it?
- The author — Ron Jeffries — is one of the founders of Extreme Programming (XP) and Agile Manifesto, so even if you won’t like the book or will disagree with it, it is still worth reading, due to legendary status of the author.
- It is a really short book, which took me 4 hours to finish (including writing a short summary for each chapter). Some chapters are half a page long.
Who should read it?
In the early praise to the book Robert “Uncle Bob” Martin specifies that this book is for:
every CTO, every VP of engineering, every director of software, and every software team leader to know how to manage teams that build high-quality software systems.
However, I would also add that even if you are junior developer or even a CS student, you will still find this book beneficial.
When to read it?
- It is best digested after having some experience in the software engineering field, particularly having negative experience e.g. of failing projects, projects that were overdue, dealing with numerous bugs in production, etc. This is because, after this kind of experience, you will be able to relate to the proposed solutions.
- For students, reading it will still be beneficial, as you will gain the theory on how things should work in the ‘right’ way.
Chapter by chapter summary
What follow is a chapter by chapter summary of the most important things (in my subjective opinion), enriched by any thoughts that I had during the reading of this book.
Part 1: The Circle of Value
The first part of the book is very structured and aims to lay out how an effective process of creating software should work.
Successful software development is hard. It will always be hard. However, doing it smoothly and gracefully has a very real simplicity
Chapter 1: The Search for Value
This chapter introduces the pyramid of value (seen on the cover of the book) and lists some high level principles needed to achieve value.
N.B. What is meant by value will be defined in the following chapter.
Some of the principles are really obvious (however, despite this they are often not followed). Here are a the most important principles:
- Teams should understand what is needed and the deadlines.
- Organise teams around features.
- Help the team build their skills.
- Select the features needed in order of priority/value.
- Build up the product feature by feature = frequent delivery of value. This also allows to see how things progressing.
- Break features down to the smallest possible size.
- Build the product as early as possible. Then enhance it.
- Be always ready to ship.
- Ensure that the product has good design and is as defect-free as possible.
Chapter 2: Value is What We Want
Values is what we want. This can be anything:
- New features.
- Software that save time or money.
- Software that saves lives.
- Software that earns money.
- Software that makes lives more convenient.
Then the chapter switches to why you need to ship the software early and frequently:
- No one needs/uses every single feature, so there is no point to wait until everything is done.
- You will get information in the form of feedback — Are you on the right track? If not, you can change direction at little cost.
The last idea explored in the chapter is to focus on small but high-value features, since these will provide the most value at the least cost. Once you ran-out of these, it is a good thing! Because the most important bits of the software has been completed.
If the remaining feature don’t justify the investment e.g. because they are too complex and will take a lot of time, whilst bringing not that much value, maybe it is time to switch to a new product/project.
Chapter 3: Guiding Goes Better “Feature by Feature”
- Know the deadline (duh).
- In the ideal world we want to do all features before the deadline. This never happens… We either don’t do everything or we are past the deadline.
- We can’t really tell how we are doing until we start the work and see the software. After we start testing, we uncover even more work that wasn’t accounted.
- As a result, we are later, we’ve done less, and what we’ve done doesn’t work that well.
- But if we used the frequent releases approach, this would be ok, since at least we would have something.
- Incremental delivery is always better — you end up with usable software early and can get feedback early. We can change features, add new ones and react to changing user needs. We are more responsive.
One of my biggest challenges was explaining to non-technical stakeholders that it is hard to say when a particular piece of work will be done. It takes a lot of business culture work to change people’s attitudes to this. What helped me is 3 things:
- Being direct and explicit that there is no objective estimate, because:
- There are often too many moving parts and unknowns.
- For people who keep insisting on the estimate, despite 2 points above, providing a short daily/weekly update of the work completed and left.
Chapter 4: Organizing by Feature
- Organising teams by skill-set is bad. Each feature will need to be passed between the teams, these handoffs will cause delays because you need to coordinate a lot.
- A better way is to build teams organised by feature — each team has people with all different skills necessary to build the entire feature (developer, tester, data engineer, data analyst, UX/UI designer, etc.). This way work can be allocated across teams easier.
- Best specialists get assigned to teams working on the most important features.
- If there are people lacking knowledge — upskill them. Create guilds/practices, which are led by the most experience people in the topic who will now be in charge of upskilling other people.
One particular thought that want to emphasise is this one:
Experts shouldn’t be highly paid because they are experts. They should be highly paid because they help other people to also become experts.
Coming from a data background, I would say this kind of organisation by feature is unlikely in the Data World. Data Analysts, Data Engineers and Data Scientists tend to stay in central teams. Sure there is interaction with engineering teams/PMs/Business People/Any other stakeholders (sometimes quite a lot) but more often there are just 50 ETL pipelines that need to migrated/fixed and this will take years to complete and then there is virtually 0 interaction with these groups…
Chapter 5: Planning Feature by Feature
- Vision and ideas should be big, but releases should be small and frequent (which is also good for management because of clear visibility of progress).
- Plan but not in conventional way — plan which features you need the most. Don’t focus on unimportant low value features.
- Detailed plans are useless, since as humans we are bad at estimating.
- Plan in this way — set up a deadline and budget. Deliver the most important things first. Be ready to ship at all times.
- How to estimate this initial deadline though? Form a team and build for a while. This way you will learn quickly and will be able to estimate somewhat objectively. The problem is that management want to know beforehand how much money and time the project will take, but you can’t really tell before actually starting…
- Carry out 2 week sprints which include small features — each feature should take 2–3 days. Don’t split this further into technical task, since business people will find it harder to track progress. If features are big — split them into smaller features i.e. a large story into smaller stories. This will take practice though.
- Team itself will know how much stories it is capable of doing. Use yesterday’s weather principle i.e. you will likely do today as much as yesterday.
- Best results are obtained by selecting the work to be done and the work to be deferred.
- Pressure of getting one more feature in the sprint is destructive — team will hurry, will leave more defects, won’t test the features, code won’t be clean. In the long-term it will cost more.
Here is one interesting metaphor which I would like to emphasize:
When there’s too much food on your plate, don’t eat it. That way lies obesity and lethargy. It’s far better to do eight things well than ten things poorly.
Chapter 6: Building the Product, Feature by Feature
- With each sprint we learn — how much feature we can do in a sprint, how to test these features, learn how to define features, how to break them into smaller features.
- Since the approach is so feature focused, business people, Product Managers (PM) and Product Owners (PO) must build a skill to translate vague requirements to practical features. There should be a clear vision what the product must do and hence what features are critical and what features are nice to haves.
- Using the approached laid out so far, all features will be small, hence they should be tested extensively — leading to them being defect free. It is not as hard as it sounds!
For me the 1st important thought in this chapter was this one:
We can’t accept “90 percent done.” Features need to be “done” or “not done”: there is no middle ground.
This chapter also includes a discussion of software design and its importance to building the product sustainably.
If you spend too much time on software design, you won’t have time to work on the features. If you spend too little time on software design, adding features will become hard in the long-term (as design will be too complex to add anything).
So what is the solution? Tweak, observe, tweak again until you reach that balance. No easy way around it.
The 2nd important (again for me) thought in this chapter was this one:
It is easy to learn good design principles but it is also easy to forget them, especially if you put teams under pressure.
Chapter 7: Build Features and Foundations in Parallel
- Feature needs to be supported by strong foundation, which in turn needs to be well-designed. Foundation in this context means architecture, design, infrastructure.
- Keep the system’s design solid from day 1.
- If we build the whole foundation first, we won’t have too much time to work on the features. But if we completely ignore the foundation, the product will not scale or worse will have defects. Best approach, build features with just enough foundation to be solid a.k.a. an MVP.
- Foundation work should really be part of the feature story.
The following observation is so obvious, yet never crossed my mind until I’ve read it:
Developers are taught to design the whole system up front. But this is never ideal, since we never know what the system will be upfront.
Chapter 8: Bug Free and Well Designed
- Think of defects/bugs as negative features. Repair them as you go and asap.
- Fixing bugs takes time. Don’t leave them until the end of the project.
- Extensive testing is the solution, particularly as design evolves and number of features grows.
- Business level test s— have we provided what we were asked for? Express the features in terms of the tests they must pass and automate these tests.
- Programmer tests — write tests first, then make them run (TDD).
- Preventing a problem in the first case is quicker than finding it and fixing it.
- You can continually improve the design by refactoring.
If you are still not convinced that you should deal with bugs asap, here is an eye-opening metaphor:
Imagine you are in a restaurant and there is a roach on the floor. Nobody will ignore it, saying that: “Let’s deal with it later, since lots of customers waiting to order” . The roach will be cleaned asap. And if not, well the customers will leave. Same story for bugs.
Chapter 9: Full Circle
This chapter is a summary of the previous 8 chapters, re-iterating the main points:
- Features are value. Deliver them early.
- Deliver working features. No such things as 90% done.
- Prioritise high value features.
- Use yesterday’s weather principle for selecting the work.
- Ensure that product is defect free and well designed.
For all of this to work, you only need one thing:
A commitment from the top of the business, down to the individual managers and developers. Everyone should be on board with this approach.
Part 2: Notes and Essays
Given the name of the part, I expected the chapters to be abstract (a few indeed were). However, majority of the chapters, explore thoughts mentioned in Part 1 from a different angle.
Good work is simple. It is not easy. The details, of course, are endless.
Chapter 10: Value — What Is It?
This chapter focuses on the point that value (which was previously defined as what we want in Chapter 2) varies from company to company.
A start-up in a dire need of funding, wants to get a prototype asap to get the funding. They want speed, hence value speed.
A company distributing vaccines, which wants to save as much people as possible, wants to save lives. They want maximum impact, hence will prioritise features/work based on how many lives it can save.
Chapter 11: Value — How Can We Measure It?
We can’t really measure how much customers will like the new feature until they actually start using. We just don’t have these numbers beforehand. Hence value isn’t really objectively quantifiable before we release something.
Monetary indicators e.g. new revenue the features are bringing are always trailing. By the time you will get these numbers it will be too late. If the feature fails — you lost all that invested time and effort.
How to measure value then?
Just compare all the features in the backlog and decide which ones to do next! If you can’t — maybe you shouldn’t be doing any of them and it makes sense to think about doing something completely different? Ask why? Not just yourself but your team, your stakeholders. Rinse and repeat.
Chapter 12: Of Course It’s Hard!
Software development is hard but the process doesn’t have to be hard. Focusing on value simplifies the process.
Chapter 13: Not That Simple
This chapter was quite short and vague but I think it can be summarised, as:
There will always be some obstacles to follow this process — corporate bureaucracy, management resistance, lack of funding, pressure to work longer hours to meet unrealistic deadlines, etc. The key is resisting these obstacles.
Chapter 14: Creating Teams That Thrive
- Ensure that your teams know what to do let them figure out how on their own.
- Having a Product Owner/Product Managers a must — someone who provide the vision, guides development, specifies most important issues.
- In an ideal world, the PO will show the team what the problem is and then the whole team will decide on how to fix it.
Some people may claim that the last point is not realistic for larger teams when you have 10–15 developers, some of which may have no background of the problem at all. But remember, the whole idea of this book is to have teams organised by feature. These teams should be small and everyone should be up to date with everything.
Chapter 15: The “Five-Card Method” for Initial Forecasting
To give an initial forecast for the project, you can use the five-card method, which works in the following way.
- Consider up to 5 most important epics that describe the product. Describe each in 1 sentence.
- Break down each epic into up to 5 smaller features.
- Keep breaking each feature into smaller features until each feature is about of the same size i.e. something that can be built in 1 week by a single person.
- As you break down the features, prioritise higher value features.
I found this chapter a bit contradicting to Chapter 5: Planning Feature by Feature, since by using the above methodology, you can arrive at some estimate for your project (number of features * 1 week). Yet Chapter 5 emphasises that it is better to start the actual work before giving any estimates.
Perhaps the five-card method should be used as a rough estimate.
Chapter 16: Managing Natural Software Development
- If teams are cross-functional, self-organising and have a PO, then they don’t need a lot of management.
- So what is management for? Well, 3 things:
- Staffing decisions — Who to fire and hire.
- Budgets — Within and across the projects.
- High-level strategy — What we should be building
This is delegation. Management should focus on building teams.
- Management should observe the results and decide if the results are aligned to overall strategy/plan/budget. If the results are not aligned, managers should adjust budgets/staffing/responsibilities.
Chapter 17: Whip the Ponies Harder
- Don’t pressure the teams to do more — in the long-run it will cause more issues — less testing, more bugs, culture of giving conservative estimates when things will be done
- Start with team productivity — ensure everyone has key skills. If not, up skill people.
- Work smarter not harder.
- Identify sources of delays and work on them e.g. is it slow decision making? Hand-offs? Work on that!
I particularly liked the point about increasing team’s productivity:
Increase productivity by increasing capability. Invest in training during work time. Nobody will study during weekends or holidays after an exhausting week of work.
Lots of tech companies fund courses for their employees, but the expectation is that these courses will be done in the employees’ free time. If instead employees are allowed to spend 2 hours per week studying/training during their work week, that is ~100 hours devoted to employee training per year.
From my personal experience, it takes me on average ~7 hours to finish a software engineering book with about 200–300 pages. With 100 hours that is 14 books per year. All read during your work, making you a better developer and an employee.
This time can also be spent on:
- Preparing for cloud platform certification exams.
- Sharing best practices across your teams.
- Trying to play around with new languages/libraries/frameworks/technologies and see how to integrate them in your work.
- Keeping your coding and problem solving skills fresh on Leetcode/Hackerrank.
- Completing non-technical courses e.g. those aimed at improving your communication skills, effectively managing a team, motivation, etc.
Then you also reap the benefit of having loyal, motivated and skilled employees, who will be producing high quality software and will be a real asset to a company.
In case if you are still not convinced and are concerned about the cost of this approach, let me answer you with an old business proverb:
CFO asks the CEO: “What happens if we invest in developing our people and then they leave us?”
CEO: “ What happens if we don’t, and they stay?”
Chapter 18: To Speed Up, Build with Skill
This chapter is just a re-iteration of focusing on good practices, specifically:
- Testing must be embedded into your process.
- Your build process should be automated — sometimes the chaotic build process is the bottleneck. But this process is relatively easy to fix and you just to have to do it once.
Chapter 19: Refactoring
- Don’t focus your work just on refactoring, it should be just part of normal work process. Think of the campground (aka the boy scout) rule — Leave the campground a little better than you found it.
- Once you work on a feature, refactor any functions/classes/modules used by the feature and/or the place where your feature will be living in your code.
There is another metaphor that is worth mentioning to explain the importance of refactoring:
Imagine the code as a straight line. Bad coding practices make the line curvy and wavy, making it hard to follow, especially at speed. Refactoring straightens the line, making it easier to follow.
Something important to add — if you have followed the best practices from the beginning, you won’t need that much of a refactoring.
Chapter 20: Agile Methods
Majority of the things in this chapter were already mentioned or are very general.
Things that were already mentioned:
- By default Scrum doesn’t explicitly mention refactoring and TDD, so don’t forget to incorporate these into your process.
- Invest in learning. It will pay off in the long-term.
- Keep the process light, even in a large team.
- Adjust and be flexible — choose what works best for the team.
- You won’t be able to plan for and control everything. Be adaptable and responsive to changes.
- Think before doing.
Chapter 21: Scaling Agile
- Agile scales up by default. There is no need to purchase expensive training courses for “Scaling Agile” that consultants sell to large companies.
- In a large organisation you scale Agile by making more and more teams to adopt Agile approaches. As simple as that.
- However, start with a few teams first. Until these teams are comfortable with Agile, don’t migrate other teams to Agile.
What did I like about the book?
This is a great book.
- Really short and straight to the point. It took me 4 hours to finish. If I wouldn’t make notes, probably it would have taken me only 2 hours.
- Extremely catchy and edgy metaphors/aphorisms. In my opinion, these are really important, as it makes it easier (and fun) to remember important things.
- The software legend with half a century of experience is sharing his wisdom with you.
What can be improved?
The only thing that I think could have been improved with this book is better chapter organisation, specifically:
- Some chapters re-iterate lots of things that were mentioned before e.g. Chapters 18 and 20.
- Some chapters could be joined with other chapters e.g. joining Chapter 2 with Chapter 10 and Chapter 11. These chapters cover the same topic — Value, albeit from different angles, yet there are 7 chapters on different topics between them.
- Some chapters are too short (and sometimes vague) e.g. Chapter 12 and 13. They could be either removed, joined to other chapters or elaborated.
However, given that the book is short already, this is definitely not a make or break point.