Beyond Fast Good And Cheap

How do we balance building the right thing with building it well? In this presentation we will examine this question at multiple levels of focus. We will discuss how a team can define the threshold for acceptable quality for their own context.

Transcript

1. Beyond Fast, Good And Cheap Alan Stevens Finding our values in the face of uncertainty
2. Contact Me Email/IM: alanstevens@gmail.com Blog: http://halanstevens.com Twitter: @alanstevens
3. June 15/16, 2012 Knoxville, TN
6. II. The Problem III. Values V. Rules I. Backstory IV. Principals
7. I. Backstory
8. I Hate Crappy Code
9. The Real World
10. Constraints
11. Priorities
12. Values
13. II. The Problem
14. The Project Triangle Fast Good Cheap pick any two
15. Fast
16. Good
17. Cheap
18. How do we balance building the right thing with building it well?
19. Building the right thing is always a higher priority!
20. I'm never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial. Ward Cunningham “Ward Explains Debt Metaphor” http://c2.com/cgi/wiki?WardExplainsDebtMetaphor
21. Can we verify that we are building the right thing?
22. The tests specify requirements in a way that does not require human interpretation to indicate success or failure. Jim Newkirk Test Driven Development in Microsoft .NET
23. Building it right has a minimum acceptable threshold which must be met
24. Once you get your systems to work, you still have to go back and clean up the wreckage left behind by the victorious battle. You are not done until the victorious code has been cleaned, polished, and oiled. “Uncle” Bob Martin “The Rush” http://blog.objectmentor.com/articles/2009/06/26/the-rush
25. The Last 10% is 50% Of The Work
26. How do we guarantee baseline design without impeding productivity?
27. Image credit : FlyoverPeople.net III. VALUES
28. The *ILITIES Agility Testability Readability Reversibility Changeability Flexibility Maintainability Coined by Kevlin Henney
29. Prevention is the best cure
30. Continuous Improvement
31. “With every mistake, I must surely be learning” George Harrison
32. As applications mature, they should become more maintainable, not less.
33. Avoid Complacency
34. IV. Principles
35. Value Developer Cycles Over CPU Cycles
36. Do the simplest thing that could possibly work
37. Follow the “Boy Scout Principle”
38. Manage Technical Debt
39. I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it. Ward Cunningham “Ward Explains Debt Metaphor” http://c2.com/cgi/wiki?WardExplainsDebtMetaphor
40. Enable Change
41. Build Architectural Seams
42. At least build fault lines
43. V. Rules
44. the code is more what you'd call "guidelines" than actual rules
45. The rest of a developer's career is spent pursuing better and better answers to the question "where should this code go?" Jeremy Miller On Writing Maintainable Code http://codebetter.com/blogs/jeremy.miller/archive/2006/12/06/On-Writing-Maintainable-Code.aspx
46. Where should this code go?
47. Don’t Repeat Yourself & Separation of Concerns
48. D RY Don’t Repeat Yourself
49. See it once: do it See it twice: notice it See it a third time: Abstract It! The Rule of Three
50. Separation of Concerns
53. High Cohesion & Low Coupling
55. When you finally realize what your program is doing, you have to go back and make it look like you knew that all along. Make it look like it was easy to write this program, even if it wasn’t. Ward Cunningham “Mastering the Craft of Programming” http://railslab.newrelic.com/2009/09/15/ward-cunningham-aboutus-org
56. Make it look like it was easy to write.
57. Thanks For Listening! Email/IM: alanstevens@gmail.com Blog: http://halanstevens.com Twitter: @alanstevens