Topic 45. The Requirements Pit
Tip 75. No one knows exactly whay they want
In the real world, exact specification are hard, if not downright impossible, to find.
Tip 76. Programmers help people understand what they want
That’s where we programmers come in. Our job is to help people understand what they want. In fact, that’s probably our most valuable attribute. (p. 407)
We need to ask questions to the client and flush out the known factors of the problem. Once we agree on a point of uncertainty, we need to explore options.
Your role in this is to interpret what the client says and to feed back to them the implications. This is both an intellectual process and a creative one: you’re thinking on your feet and you’re contributing to a solution that is likely to be better than one that either you or the client would have produced alone. (p. 409)
Tip 77. Requirements are learned in a feedback loop
Your job is to help the client understand the consequences of their stated requirements. You do that by generating feedback, and letting them use that feedback to refine their thinking. (p. 410)
The essence of the work of programmers is interpreting what the client wants → so we need to ask the question: “is this what we want?” a lot.
Tip 78. Work with a user to think like a user
Walk in your client’s shoes.
Tip 79. Policy is metadata
Implement the general case, with the policy information as an example of the type of thing the system needs to support.
Documenting Requirements:
The best requirements documentation is working code.
Documentation is important but, it’s not deliverable to the client.
These documentations are mileposts to help guide the implementation.
Requirement docs are not for clients:
The client will probably never read them.
The requirement documents contains detailed information and subtleties that are incomprehensible to the client.
Requirement docs are for planning:
Requirement docs should contain short descriptions (user stories) that explain what a small portion of the application should do from the perspective of a user of that functionality.
By keeping this statement of requirements short, you’re encouraging developers to ask clarifying questions. You’re enhancing the feedback process between clients and coders before and during the creation of each piece of code. (p. 415)
Good requirement docs:
Requirement docs should be abstract.
The simplest statement that accurately reflects the business need is best. However, you must capture the underlying semantic invariants as requirements, and document the specific or current work practices as policy.
Requirements are not architecture. Requirements are not design, nor are they the user interface. Requirements are need. (p. 415)
Feature bloat (or creeping featurism, or requirements creep):
When the scope of the project increase as the development progresses. (Entropy)
Solution: iterations with constant feedback.
Tip 80. Use a project glossary
Project glossary: documents that defines alll the specific terms and vocabulary used in a project.
→ ensures consistency
All participants in the project, from end users to support staff, should use the glossary to ensure consistency. This implies that the glossary needs to be widely accessible—a good argument for online documentation. (p. 416)
Topic 46. Solving impossible puzzles
The key to solving puzzles:
- recognize the constraints placed on you
- recognize the degrees of freedom you do have
Tip 81. Don’t think outside the box - find the box
When faced with an intractable problem, enumerate all the possible avenues you have before you. Don’t dismiss anything, no matter how unusable or stupid it sounds. Now go through the list and explain why a certain path cannot be taken. Are you sure? Can you prove it? (p. 412)
We need to identify the most restrictive constraints first, and fit the remaining constraints within them
To prepare yourself on difficult problems, your non-conscious mind needs to have plenty of raw material.
Feed your brain with feedback on what works and what doesn’t work as you do your daily job. → keep an Engineering daybook
Topic 47. Working together
Tip 82. Don’t go into the code alone
Pair programming: one person typing code while one or more other team members comment, ponder, and solve problems together
The developer acting as typist must focus on the low-level details of syntax and coding style, while the other developer is free to consider higher-level issues and scope.
Topic 48. The essence of agility
Tip 83. Agile is not a noun; Agile is how you do things
The values of the Manifesto for Agile Development:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract neogotiation
- Respond to change over following a plan
→ The values are motivated and informed by the continuous act of uncovering better ways to produce software. It’s a suggestion for a generative process.
Working in an agile way:
- Work out where you are
- Make the smallest meaningful step towards where you want to be
- Evaluate where you end up, and fix anything you broke
