The Nature of Software Development · guh.me - gustavo henrique's personal blog

My personal notes on the book The Nature of Software Development.

The Search for Value

Value: is “what you want.” It can be any kind of value, from money to laughs or lives.
Guiding: we produce value by creating teams with responsibility for creating value. We make sure they understand what is needed, and understand the time available. We guide them by observing what they actually build.
Organizing: we organize teams with the ability to get the job done. We organize around features, because features give us the ability to plan and build value most rapidly. We apply good people and help them build their skills.
Planning: we steer our projects by selecting the features we need, in the order we need them. We produce value in a timely fashion.
Building: we build up our product feature by feature. This provides frequent delivery of value. We can see how things are progressing early and often.
Slicing: we slice features down to the smallest possible value-bearing size. We build a capable product as early as possible, and then enhance and grow it as the deadline approaches. We’re always ready to ship.
Quality: we apply the necessary practices to ensure that our product always has a good design and that it is as nearly defect-free as possible. We’re able to build value continuously, sustainably, indefinitely.

What kinds of value does your project deliver to its users? To your organization? To the team? What value does it deliver to you?

The main thing to remember is that we get the best results from delivering the software, feature by feature.

Guiding Goes Better “Feature by Feature”

With a monolithic project, late in the game we can’t do much to cut costs. We have already written requirements for things we’ll never get. We’ve designed and even written code for things that we’ll never complete.
Let’s plan for multiple releases from the very beginning. Multiple releases are easier to manage and deliver value sooner. It’s even easier to build the software that way. Everyone wins.
A project that delivers feature by feature is more predictable.
Feature by feature gives better information, better guidance, better results.
When we build our software projects feature by feature, things go better. We can see how much is done and how rapidly the project is progressing. We get a good sense of how much will be done by any given date.
When our projects grow feature by feature, we can respond to what’s really happening. We can respond to the changing needs and inputs of the business and of management.

Organizing by Feature

We want to get value in small bites: features. We prosper when we manage in terms of value, in terms of features.
Organize into small teams, each of which builds features that the Product Champions can understand. Make sure that each team has all the people and all the skills necessary to build the entire feature, not just part of it.
Soon, you might find yourself creating a team whose database person, or UX person, really isn’t quite good enough. Super. You’ve identified a training opportunity. A learning opportunity. An opportunity to form a guild, a Community of Practice!
- Build it around the people who used to be in the database or UX group, and include all the people who are now charged with doing those things on your feature teams. This isn’t a new department: the people belong to the feature teams.
- Your top people shepherd the less experienced ones. They drop into other teams and help them, making sure that the real team member retains responsibility and learns what needs to be done and how to do it.

Planning Feature by Feature

Things go best with frequent releases of software. Value grows faster and better. Management gets visible progress at short intervals. Development works best with small, clear objectives.
We do need to plan. We don’t need a detailed list of what will happen and when. When the time comes, let’s decide then what to do next.
It’s important to identify key features that we’ll need to have early, as well as features we can’t live without. Let’s identify and record those.
Set a time and money budget; produce the most valuable features first; keep the product ready to ship at any time—and stop when the clock runs out.
Ideally, we would begin just by beginning. Get an idea, think about it a bit, put together a little team, and start building. That will tell us quickly whether we can produce something of value, and about how long it will take. Then we can decide to cut our investment, to keep going, or to invest more.
It’s not good enough to plan just at the beginning. Because we’re focused on value, we need to plan all the time. The team should be working to a fixed cadence, often called iterations, or sprints, a couple of weeks long. Things go best if each feature, often called a story, takes only two or three days to do.
It’s better to break down stories into smaller stories, each making sense to the business-side people.
The team itself should decide how much work it can accomplish in the next two-week interval.
We plan each iteration right before it begins. To decide how much work to take on, we need to understand the work. As a team, we discuss the work. The team’s Product Champion presents one feature at a time, followed by a brief team discussion about what it’ll take to accomplish the feature. Everyone stays engaged, and the team understands the feature before committing to do it.
As the project proceed, we plan every couple of weeks, we decide what the next most important things are to do, and the team decides how many of them to take on.Choose the most valuable ideas first — that’s how we grow value most rapidly.

Building the Product, Feature by Feature

Build a tiny product, completely, in each small cycle

We need to sharpen our vision of what the product must do—and what’s just “nice to have.” The result is a faster return on our software investment.
Always work on the highest possible value next

Refine the product vision

It’s critical to do the most valuable features first.

Identify real progress

The feature-by-feature style includes a complete development cycle in every iteration: requirements, design, coding, and testing. They are all present all the time so that they’re all visible all the time.
When we can see real, running features, we have clear and solid information about our project’s condition.

Eliminate the test-and-fix finish

For feature-by-feature development to work, the software needs to be nearly free of defects at the end of every two-week iteration. It needs to be nearly free of defects all the time.

Grow and refine the design as we go

As we build feature by feature, being free of defects isn’t enough. We also need to grow the design as we go.

Build Features and Foundation in Parallel

Everything we build must rest on a solid foundation

We often use words like architecture, design, or infrastructure when talking about the foundation.
Foundation first means too few features get to market.
We dare not build the foundation first: it will defer and inevitably reduce the product’s value.
Building complete features one at a time still means too few features get to market.
If we build complete features one after another, we’re likely to have key capabilities missing when time runs out.

Build simple yet functional versions first

To get the best product in the time available, we need to work on all the features that are important to our users, not just a few. For each feature, we need to fill in as much capability as time permits, using our judgment as to what’s needed and how much time we have left.
We build what’s called a “minimum viable product” as quickly as we can.

Refine each feature in multiple iterations

Each feature version makes the product a bit better so that we always have the best possible product at every moment.
Steer to the best possible result by the desired shipping date. Because we have the best possible product at every moment, we have the best possible product at the moment we decide to ship it.

Bug-Free and Well Designed

Our product is made up of a growing set of correctly working features, built on a growing, evolving foundation of design.
Defects amount to negative features. Progress is uncertain. Eliminate defects to provide clarity on what’s done.
Defect repair adds unknown delay. Repair as you go to provide clarity on what’s done.
If we don’t know in time what’s done, and how well it’s done, we’ll have no choice but to ship late with visible defects. That’s bad business.
Because features are being added and enhanced, and because the design is evolving, we will make mistakes. We need continuous comprehensive testing.
At the end of every iteration, we need business-level tests to verify that we have received what we asked for.
The best known way to keep up is to express our features in terms of the tests they must pass, and to automate the tests to give us assurance that the feature works now, and from now on. This is often called acceptance test-driven development.
Developers make changes every day. To ensure they don’t waste time, developer tests need to be checked much more frequently. The best way we know to do this is to write the developer tests first, then make them run. This is called test-driven development, or TDD.
Almost paradoxically, all this testing makes our team go faster! The reason: We make fewer mistakes, and they’re found more quickly.
At the beginning, there are only a few small features. The design can be simple.
Remember, we’re working incrementally. We’re shipping real working features every two weeks. We need a good design early on, but we only need a small good design. As the system grows feature by feature, the design needs to grow.
At each stage of feature building, the team must do enough design improvement to keep up.
Keeping the design good as it changes is called refactoring. Refactoring is a necessary skill for this way of developing software. Failure to keep the design good enough will slow progress, or even stop it!
Testing and refactoring work together to make feature-by-feature development possible.

Full Circle

The Natural Way of developing software

Value is what we want.
Features deliver value.
Delivering features early gives us value sooner.
Managing by looking at value works better than managing by dates or artifacts that don’t deliver value.
Planning features is easy enough to do.
Estimate if you must.
Selecting the work based on Yesterday’s Weather works better.
Building by features requires us to build a small, complete product, every couple of weeks.That product must always work correctly, and it must always be well designed.
Development must deliver real working features.
The product must be well tested. Business-side people and developers contribute to testing.
The product must be well designed. Developers keep the design alive all the time.

Value — What Is It?

Value is, simply, “what you want”, what you care about.
The problem of the “Product Owner,” of management, of all the people who decide what we should do next, is to look deeply at the many things we value, and to choose a sequence of development that gives us the best possible result in return for our time, money, and effort in building our product.

Value — How Can We Measure It?

Big differences are important; small ones aren’t. When we look at all the feature options before us, some of them are incredibly important, and some are really dull and boring. That’s the distinction that matters: what’s incredibly important versus what’s boring.
Different kinds of value aren’t comparable.
Focus on what we value, so we can get the best results. Produce real software often so that we can learn what we want. Build what we want in small steps, so we can see how we’re doing. Learn the planning, management, and technical skills that we need, so we can build the product rapidly and well.

Creating Teams That Thrive

Purpose comes from the business. A dedicated business-side person is needed to guide your development team by identifying what’s to be done and what’s to be deferred. This designated person is sometimes called the Product Owner, or the Customer.
The Product Champion provides purpose, both broadly and in detail, and keeps in daily contact with your team, ensuring that they understand why the effort exists, what the most important issues are, and how the product can best serve those issues. Bring concerns or problems to the team, and let the whole team create solutions in concert.
Autonomy gives the team responsibility. The Product Champion shows what problem to solve; the team decides how to solve it.
Mastery comes from the iterative process. In each iteration, our team works to produce a “done” increment of software. At first we will have difficulty, but in each iteration, we meet and look back on how things went and determine how to do better. We move toward mastery.

Managing Natural Software Development

When we work in the Natural Way, much of the “managing” is done inside the team.
The team is fully cross-functional and has all the skills and capacity needed to deliver each increment of software. Team members do their own testing, their own documentation, everything. The closer we get to this ideal, the less coordination we need.
The Natural Way of software development calls for delegating authority to the people who do the work.
The most valuable thing you can do to speed up development is to build skill in the development team. That investment will pay off rapidly in less time lost to fixing defects, and in smoother development. Don’t confuse thrashing with effective performance. The fastest teams move smoothly and gracefully.

Refactoring

Reminder: we need steady progress. To keep progress steady, we need a clear, clean design all the time. To accomplish this, we must refactor.
The word refactoring refers to a simple, regular process of keeping the code clean.
Bad work is hard to see. We can’t see it from the outside: it’s under the surface. But as businesspeople we need the work to be good. We should expect and demand that the team keeps the code clean. And if we notice erratic progress or a slowdown, it’s probably time to bear down on cleaning things up again. That means it’s time to lighten up on the pressure.
Campground Rule: leave the campground a little better than you found it. Every time we do a feature, we start by cleaning up the area where we are going to do the work. We don’t have to make it perfect, just sufficiently better to help our feature ease in. And once our feature works, we clean up the code as we always should—plus a bit more.