Balancing Technical Debt and Clean Code
- 1. Balancing Technical Debt and Clean Code @dave1010 Dave Hulbert
- 9. Code of Conduct Carry out your professional responsibilities with due care and diligence in accordance with the Relevant Authority’s requirements whilst exercising your professional judgement at all times
- 12. Developers ● Skilled, Passionate, Healthy, Focused, Disciplined ● Conferences, user groups, meet ups ● Read books, blogs, code ● Write code, Open Source contributions
- 14. How to develop quickly (in the short term)
- 15. ● Less testing ● Less planning ● Less communication ● Don't improve tools / processes ● Overtime ● Outsource
- 19. Technical Debt
- 20. Shipping code before it's ready
- 25. uberhumor.com
- 27. Visible Invisible Good Features Bad Defects
- 28. wikimedia.org
- 29. Visible Invisible Good Features Architecture Bad Defects
- 30. amazon.com
- 31. mirror.co.uk
- 32. Visible Invisible Good Features Architecture Bad Defects Technical debt
- 34. Technical Debt
- 36. Good idea ● You think you'll be better off in the future ● The risk (interest) is manageable
- 38. Interest ● More user support needed ● Manual tasks ● Complete rewrite in future
- 39. Consequences ● Less time on new features ● Higher cost of new features ● Harder to estimate new features
- 40. bbc.co.uk
- 42. Complexity
- 44. We need to recognize that our job isn't about producing more code in less time, it's about creating software that is stable, performant, maintainable and understandable (to you or someone else, a few months or years down the road). Matthew Gertner
- 46. Invest in code
- 50. TDD ● Run every bit of code that you write, ASAP
- 51. Write a test when you fix a bug
- 53. Domain-Driven Design ● Model the domain completely in classes that don't touch the UI, database or framework
- 55. How do you keep technical debt to a minimum?
- 57. Refactoring ● Restructuring without changing behaviour ● Makes it easier to read, understand, test, change, add new features to
- 59. Refactoring ● Inject dependencies ● Eliminate dependencies ● Create interfaces to type hint to ● Extract functions ● Rename ● Reduce cyclomatic complexity ● http://refactoring.com/catalog/
- 60. Estimating ● Estimates for new features need to include refactoring – (if you don't want to increase technical debt) – Refactoring doesn't add perceived value so it's hard to sell
- 61. Debt is expensive ● Paying technical debt with interest takes more time than continual refactoring
- 62. bonkersworld.net
- 63. Break the rules
- 64. ● Help you deliver faster in the short term ● Long term strategy ● Disposable prototype ● Just don't need to write clean code
- 66. Sprint vs Marathon Sprint (example) Marathon (example) Peripheral component (logs) Central component (DB) Trivial (make a CSV) Complex (search algorithm) Few consequences of bugs (game) Important (nuclear reactor) Isolated (contact form) Reused (authentication) Abandonable (migration script) Continued updates One developer Big team Time & money to pay technical debt later Long term delivery
- 67. Investment in code is a balance