7 Comments
User's avatar
Kevin Rutherford's avatar

This proto-chapter was still valuable -- thanks for sharing it!

Expand full comment
Valentin Tudor Mocanu's avatar

I don't know if I'm thinking the same things.

It is useful to deliver sooner and more often. The client can use the software, I can get feedback (and get paid). This "small releases" approach has also other advantages (reduce complexity and others).

On the other hand, I would like this kind of collaboration to continue indefinitely. What can software design offer me?

I will design for current requirements. I make it somehow adaptable. I will apply tidy first for more adaptation. I will also evolve the legacy design based on the knowledge I have now.

Expand full comment
Kent Beck's avatar

There’s a magic I haven’t been able to describe yet where combing tidy first & after tends to make the software easier to change in the future. Not always, but often. Maybe this comes from increasing cohesion. Need to think more.

Expand full comment
veganaiZe's avatar

Best chapter yet.

Expand full comment
Kim Gräsman's avatar

With the right structure, you could realize the valuable behavior sooner. With the valuable behavior you could finance the right structure sooner. Discuss.

Expand full comment
Kent Beck's avatar

“The right structure”, “the right behavior”—no such things. Good enough behavior to attract capital to improve behavior & structure (capital can come from revenue or investment).

Expand full comment
Ricardo Gamba's avatar

_Good enough_ seems the key in every case. Even after capital/revenue flows in, we then improve it but _just enough_

Expand full comment