Notes from the book Specification by Example by Gojko Adzic

    I`m starting a series of posts which has reviews and notes of some of highly impactful books on software development specifically for programmers, This series will naturally called /labeled as "Reviews" and "Notes"
    Other Names of Specification by Example methodology

• Agile acceptance testing
• Acceptance Test-Driven Development
• Example-Driven Development
• Story testing
• Behavior-Driven Development

    Below is the notes from the book Specification by Example authored by Gojko Adzic

1. The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency. - Bill Gates
2. Building the product right and building the right product are two different things. We need to do both in order to succeed
3. A boomerang is a story or a product backlog item that comes back into the process less than a month after it was released. The team thought it was done, but it needs rework.
4. Shotgun surgery is a classic programming anti-pattern (also called code smell ) that occurs when a small change to one class requires cascading changes in several related classes.
5. Successful teams push back for more information about the real problem and then collaborate to design the solution
6. Understanding why someone needs a particular application and how they’ll use it often leads to better solutions
7. Even without high-level control of project scope, teams can still influence what gets built by: • Actively challenging requirements • Understanding the real business goals • Understanding who needs what functionality and why
8. When you’re given requirements as tasks, push back: Get the information you need to understand the real problem; then collaboratively design the solution.
9. If you can’t avoid getting tasks, ask for high-level examples of how they would be useful—this will help you understand who needs them and why, so you can then design the solution.
10. To derive the appropriate scope, think about the business goal of a milestone and the stakeholders who can contribute or be affected by that milestone.
11. Start with the outputs of a system to get the business users more engaged. 
12. Reorganize component teams into teams that can deliver complete features.
13. Investigate emerging techniques, including feature injection, user story mapping, and effect mapping to derive scope from goals effectively.
14. Specification by Example relies heavily on collaboration between business users and delivery team members.
15. Everyone on the delivery team shares the responsibility for the right specifications. Programmers and testers have to offer input about the technical implementation and the validation aspects.
16. Using a single set of examples consistently from specification through development to testing ensures that everyone has the same understanding of what needs to be delivered.
17. Examples used for illustrating features should be precise, complete, realistic, and easy to understand.
18. Specification should be • Precise and testable • A true specification, not a script • About business functionality, not about software implementation
19. Business users will often think about performing an action through the user interface or through several steps, explaining how they’d use the system to achieve something instead of what the system is supposed to do. Such examples are scripts, not specifications.
20. Ideally, a specification should not imply software design. It should explain the business functionality without prescribing how it’s going to be implemented in software.
21. Avoid writing specifications that are tightly coupled with code.
22. Good trick for writing the description is to write only the examples first and then try to explain them to someone else. Capture what you said while explaining the examples, and put that in the header of the specification.
23. When automation is done along with implementation, developers have to design the system to make it testable.
24. Postponing automation is just a local optimization. You might get through the stories quicker from the initial development perspective, but they’ll come back for fixing down the road. David Evans often illustrates this with an analogy of a city bus: A bus can go a lot faster if it doesn’t have to stop to pick up passengers, but it isn’t really doing its job then.
25. Don’t check business logic through the user interface
26. Collaboration on requirements builds trust between stakeholders and delivery team members 
27. Many companies I worked with use a software development model that’s based on a lack of trust. Business users tell analysts what they need but don’t trust them to specify it properly and require sign-off on specifications. Analysts tell developers what they need but don’t trust them to deliver, so testers need to find some way to check independently that developers are honest. Because developers don’t trust testers—they don’t cut code— whenever testers report a problem, it’s marked as impossible to reproduce, or it appears with a note like, “It works on my machine.” Testers are trained not to trust anyone,almost like master spies.A model based on mistrust creates adversarial situations and requires a lot of bureaucracy to run.