Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Project reality

645 views

Published on

Controlling Complexity, Eliminating Technical Debt, & Chimera Pet-Care

Published in: Software
  • Be the first to comment

Project reality

  1. 1. / Controlling Complexity, Eliminating Technical Debt, & Chimera Pet-Care Illusions of Engineering Wednesday, September 16, 2009
  2. 2. Technical Debt Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not- quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise. Ward Cunningham: “ ”Wednesday, September 16, 2009
  3. 3. Technical Debt Misunderstood Interest on technical debt is time spent on “not-quite-right” code. Wednesday, September 16, 2009
  4. 4. Technical Debt Misunderstood I find that many developers poorly define “not-quite-right” Wednesday, September 16, 2009
  5. 5. Technical Debt: Developer’s Perspective Lack of elegance. Lack of extensibility. Wednesday, September 16, 2009
  6. 6. Technical Debt: Engineer’s Perspective does not meet: functional specifications; security requirements; performance requirements. Wednesday, September 16, 2009
  7. 7. Technical Debt Misunderstood Why? Wednesday, September 16, 2009
  8. 8. Technical Debt Understood Fixing function, security or performance issues is part of the original project on the original budget. Wednesday, September 16, 2009
  9. 9. Technical Debt Understood New functional requirements have new budgets and the cost of refactoring existing components can and must be included. Wednesday, September 16, 2009
  10. 10. Technical Debt Understood Choosing to not refactor when needed converts technical debt into financial debt. Wednesday, September 16, 2009
  11. 11. Technical debt as a tool Debt is a financial instrument; Technical debt is a software engineering instrument. Wednesday, September 16, 2009
  12. 12. Technical debt as a tool If you do not use it, you will not keep up. If you do not manage it, it will suffocate you. Wednesday, September 16, 2009
  13. 13. Safe technical debt Lack of elegance. Lack of extensibility. Rapid prototyping. END. Wednesday, September 16, 2009
  14. 14. Typical technical debt Lack of documentation. Lack of optimization. Wednesday, September 16, 2009
  15. 15. Risky technical debt Lack of complete function. Lack of complete tests. Lack of architectural design. Wednesday, September 16, 2009
  16. 16. Reality 80% of elegance is useful, 20% is self-indulgence. We call this part “good engineering.” Wednesday, September 16, 2009
  17. 17. Reality You likely have no idea how someone (even you) will want to extend your code. Wednesday, September 16, 2009
  18. 18. Reality 100% of premature optimization is wasteful. Not all optimization is premature. Good luck. Wednesday, September 16, 2009
  19. 19. Reality • Implementation averaged 25% over budget [1] • 52.7% will cost 189% of original estimates [3] • First year supports costs were underestimated an average of 20% [1] • 40% failed to achieve their business case within a year of launch [1] • 75% or more blew their schedules by over 30% [2] • 31.1% will be canceled before they ever get completed [3] [1] The Conference Board Survey (2001) [2] The KPMG Canada Survey (1997) [3] The Chaos Report (1995) Wednesday, September 16, 2009
  20. 20. RULE I TODOs related to function or security shall not be used. Instead try function or security. Wednesday, September 16, 2009
  21. 21. RULE II Observe the Principle of Least Surprise Wednesday, September 16, 2009
  22. 22. RULE III Keep It Simple, Stupid Wednesday, September 16, 2009
  23. 23. RULE IV If your code isn’t elegant it’s worth less. If your code doesn’t work it’s worthless. Wednesday, September 16, 2009
  24. 24. RULE V Write functional tests. Wednesday, September 16, 2009
  25. 25. RULE VI Always use best coding practices. Wednesday, September 16, 2009
  26. 26. RULE VII Optimize everything* * consider the optimal approach to each problem and articulately justify using anything else in comments/documentation Wednesday, September 16, 2009
  27. 27. The Truth The “Truth” is software engineering is a hard balance Wednesday, September 16, 2009
  28. 28. The Truth Technical debt must be measured along side: financial budgets, time budgets, opportunity costs, expected project longevity. Wednesday, September 16, 2009
  29. 29. Parting thought I challenge you to be a better engineer and align your goals with those of the project. Wednesday, September 16, 2009

×