(2022-01-23) Jeffries Strawberries7 Implications

Ron Jeffries: Strawberries 7: Implications. We begin our product journey with high hopes and grand wishes, including a lot of features

That’s the Behavioral shadow as we envision it: what the product does.... As for the Interpretive shadow... When we think of the Reactive shadow...

There’s our product goal: a coherent grouping of valuable capabilities, with a clearly understandable design, and, even more, a design that is readily changed.

Nothing to it. At least not until we start.

We know on day one that we’ll be growing the product.

And we have to be ready to release.

We may have the final design more or less in mind. It is my view that a few days spent thinking about the design before coding is only a few days wasted, so it can’t really hurt and might help. (But) I wouldn’t recommend spending weeks or months designing.

Our first increment is tiny. It does just a one tiny thing.

As we build this thing, we need to be confident.

One good way to have that confidence is via testing.

If the product does a lot of complex operations, or the domain is messy–like, say, tax–we may well want a growing suite of tests that can be understood by the business-side people on our team. We may call these Acceptance Tests, but I prefer the term Customer Tests.

I freely grant that some thinkers feel that these business-level tests are not needed. I also grant that my own view changes. Sometimes I think our Programmer Tests, which I’ll come to in just a moment, will give us enough confidence.

At the development level, the programmer level, I think they are a sine qua non. In addition, I think they are absolutely necessary and cannot be done without. (TDD)

When I do not have that open-do-close bracket of a micro test, my confidence in the code declines slowly, and my tension increases slowly.

The tests serve to help with all three shadows.

But then, by Wednesday or Thursday, we do the second capability.

we do more and more. We have a half dozen capabilities, then a dozen. Often, if we are not very careful, our interpretive design shadow and our reactive flexibility shadows will be showing trouble

We cannot allow this! If we were to allow it, each new capability would be harder to design, because our design is not clear to us. It would be harder to install, because our code is not responsive to our attempts to change it.

Continuous Design Improvement (refactor)

we have to make sure that all three shadows are good, before and after each added capability.

It’s tempting to let it go, clean it up later. That’s always a mistake.

as long as we let that cruft remain in the shadows, every feature will cost a bit more than it should.

The most likely outcome of this spiral is more and more defects, slower and slower development, dogs and cats living together, general unpleasantness, and a much less satisfactory product.

Instead

For every feature, let’s do our best to bring the design back to understandable, future changes easy to make.

we need to keep our system clear in our minds and flexible in its code, so that we do not slow down.

The three shadows, behavioral, interpretive, and reactive, can each be observed as we create our many increments of software. Each one needs to be brought along together with the others.

Now the truth is, we can’t do this perfectly, but we can do it far better than our worst day.