Sometimes I’ll get a ways into a chapter & realize I need to start over. Rather than just throw a chapter away this time, though, I figured I would share it with all y’all. This way you can see some of my writing process, you’ll be able to see how much the chapter changes between now & publication, & maybe you’ll get a little something out of it.
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.
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.
With the right structure, you could realize the valuable behavior sooner. With the valuable behavior you could finance the right structure sooner. Discuss.
“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).
This proto-chapter was still valuable -- thanks for sharing it!
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.
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.
Best chapter yet.
With the right structure, you could realize the valuable behavior sooner. With the valuable behavior you could finance the right structure sooner. Discuss.
“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).
_Good enough_ seems the key in every case. Even after capital/revenue flows in, we then improve it but _just enough_