This document discusses why developers should slow down their work instead of focusing only on speed. It argues that perceived velocity is different from actual quality and that working too fast can lead to technical debt from bugs and lack of refactoring. It suggests taking time for specifications, estimates, testing, refactoring, commenting code and continuous learning to maintain high quality over speed of delivery.

1. Slow Down

2. Why should you slow down?

3. Myth: A Fast Developer is a Good Developer

4. Project Velocity

5. Perceived Velocity

6. Actual Velocity

7. Ideal Velocity

8. Project Momentum

9. What don’t you do when you work too fast?

10. Don’t Live with Broken Windows

11. Comment First

12. Refactor Continuously

13. Test Driven Development

14. Never Stop Learning

15. How can you slow down?

16. Insist on Formal Specifications

17. Estimating

18. The End