TIL (Today I Learned) - Programmatic programming #8

Today's 3 Line Summary

Requirements rarely lie on the surface, so you should try to produce mockups and prototypes for customers or become a client.
When faced with an intractable problem, enumerate all the possible avenues you have before you. sometimes it is useful to do something different.
The agile team should experiment continuously, and need a good design for easy change.

2022.04.03

Chapter 8 Before the Project

Requirements rarely lie on the surface. Normally, they’re buried deep beneath layers of assumptions, misconceptions, and politics. Even worse, often they don’t really exist at all.
In those cases, Pragmatic Programmers rely on the “is this what you meant?” school of feedback.We produce mockups and prototypes, and let the client play with them.
There’s a simple technique for getting inside your clients’ heads that isn’t used often enough: become a client.
We believe that the best requirements documentation, perhaps the only requirements documentation, is working code. But that doesn’t mean that you can get away without documenting your understanding of what the client wants.
Good requirements are abstract. Where requirements are concerned, the simplest statement that accurately reflects the business need is best.
What can we do to prevent requirements from creeping up on us? The answer (again) is feedback.
Create and maintain a project glossary—one place that definesall the specific terms and vocabulary used in a project.

When faced with an intractable problem, enumerate all the possible avenues you have before you.
This is an ideal time to do something else for a while. Work on something different.
And always remember the advice on the cover of The Hitchhiker’s Guide to the Galaxy: DON’T PANIC

Throughout this book we recommend working closely with users; they are part of your team.
Don’t Go into the Code Alone

It all boils down to how you deal with uncertainty.
A team that doesn’t continuously experiment with their process is not an agile team.
To make this whole agile thing work, we need to practice good design,because good design makes things easy to change. And if it’s easy to change, we can adjust, at every level, without any hesitation.

In my work, I often organize my customers' requirements, rather than programming. In that respect, this chapter was very helpful.
I have done pair programming in training, and it was nice to experience. When I write code, I tend to talk to myself a lot about the issue. In pair programming, there was a person who talk to it, so I can find the solution more quickly.
I want to try Agile next time. I should keep in mind what I read in this chapter when I try Agile.