Tidy First? A Daily Exercise in Empirical Design - Kent Beck
The idea of XP
Strip software development back to its essence and little of other stuff as possible. Geeky people talking to people with needs.
The speaker wanted to have an updated version of the book “Structured design” when writing his book tidy first. The heart of those book is that coupling is the key issue in software design.
Coupling definition in the book "Structured design" : two elements in a design are coupled if when you change one, you have to change the other.
Software design is an exercise in human relationship.
Human relationship is really important in software design because the reason we had trouble with software design wasn’t because we don’t know what to design, but because we didn’t get along as trust is lost (delay, different incentives, …).
We need superior skill as designers in service of the relationships in software development.
tidy first
Book is bout brutal scope cutting.
It boils down to moments that a programmer encounters several times a day: there’s a code, I need to change it, it’s a mess, do I tidy first? The answer is probably yes, but sometimes no.
tidy first is all about the relationship with yourself.
Kent Beck is writing a second book tidy together, where it’s about teams of programmers working together. So with interpersonal relationships.
As designers / programmers, we are not just interacting with code anymore, we are interacting with our whole team, maybe not this moment, but overtime.
There will be a trilogy:
- 1st book tidy first is about you and yourself
- 2nd book tidy together will be about your immediate colleagues
- 3rd book will be the relationship between technology and business
Software design at a highest level
Why do we design? So we can change it. We have software, it runs the way it runs, the computer doesn’t care how it’s designed if we don’t have to change it. It’s only when we want to change its behavior in some way that the design becomes important.
IDEA <------> FEATURE
^ ^
| |
~|~~~~~~~~~~~~~~~|~~~
| |
+-> STRUCTURE <-+
The structure of the system profoundly affects how expensive those features will be to implement. The structure is never right, never perfect.
Structure is only indirectly observable:
- investors and the users of the software might be able to see that features are coming more slowly than it’s used to be
- there’re more defects than there used to be
That’s caused by an under-investment in structure. But by then, it’s way too late.
The goal of empirical software design is to bring balance to the investment in features and its structure.
Magic in software is sometimes you implement a feature, and that make you realize the structure could be better. And structure can also suggests ideas.
Software as a magical nonlinear payoff function where sometimes you can cross a threshold and either dramatically increase the value of a feature or dramatically reduce its cost.
So we should aim for those “jackpot” moments.
Software design
Constraints on any style of design:
Social constraint
We have to get along to build and maintain trust. We have to repair relationships when they’ve been damaged, e.g. change in API.
The way to address that is to align Authority and Responsibility.
If I create work for others, at least help do that work. Better yet, do not create work for other people. It’s the responsibility of the designer to make sure everybody learns what they need to learn in order to adapt to the new design change. The responsibility of the designer extends throughout the social relationships.
There’s also the Incentive constraint, as you need to recognize that everybody’s incentives are not the same, e.g. product organization whose incentives are aligned with features, whereas engineering organization whose immediate incentive are more aligned with structure, and those two don’t match up.
Acknowledge incentives diverge and yet we have to come together in order to get our needs met.
Third constraint: Change.
Juniors don’t stay juniors forever, people go, people come, market changes. The social structure that you build is going to change over time.
Documentation is not going to fix this problem of social change.
Software
Software is different than other mediums for engineering:
- Cost: the cost of software is mostly in the cost of changing the software, not writing it in the first place.
- All the changes are not the same. The cost of the changes is actually the cost of those big changes mostly. They happens because software is broken into a bunch of parts.
- This is a natural process that results in avalanche.
- We don’t have the cost of change to be expensive.
- Coupling
- Renaming a class using an IDEA, i.e. with a single operation, to perform the whole change in the codebase cannot be counted as coupling.
- Coupling is about the propagation of change.
- External coupling is even more expensive.
- You are in constant trade-off space.
Economic
Well-intentioned advice about software design that ignores economic realities do not work in the long run. If somebody is paying you to design the software, you can’t ignore it for long.
The whole big-design up front isn’t ineffective because it’s stupid or hubristic, but because it ignores the economic drive, because we want our activities to be sustainable.
3 economic imperatives:
- Survival
- Software starts in a default mode, which is in failure mode. Only when you cross a threshold can you say the software is going to last quite a while.
- If you ignore the two phases explore and expand, the software will not survive at all, i.e. why spend time on something that is just going to fail.
- Whatever the software design we choose is going to have to improve the chances of the survival of the software through those early years.
- Net Present Value: time is money.
- Learning sooner is exactly the same as earning more.
- Spending later is exactly economically equivalent to spending less.
- Software design style that pushes costs out into the future is creating value, even if you may more later, the trade-off may be fine.
- NPV is why design up-front is a bad idea.
- Optionality: What can I do with this software in the future?
- Software design is preparation for change. The more changes you can make in more different directions, the more valuable the work you’ve done is.
- The less predictable your environment is, the more the options are worth.
Implications
- Grow like a tree.
- Design is an activity, and it’s going to be taking place periodically as we go along, that requires a different style.
- We want to bring balance to the investment in features and in structure.
- Interruptible: we have to be able to interrupt the design change in order to get back to features.
- Parallels: have the old and new designs exist for a time in together, at all scale.
- Purpose
- Software design is a creative activities and hence need space and impetus.
- Leading with purpose instead of pressure is what creates that that combination of impetus for change and space for creativity that allows to more fully realize our potential as programmers.