Downloaded 12 times
More Related Content
Similar to Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
- 1. Balancing Technical Debt and CleanCode @dave1010 Dave Hulbert
- 2.
- 3.
- 5.
- 6.
- 7.
- 8.
- 9. Code of Conduct Carryout your professional responsibilities with due care and diligence in accordance with the Relevant Authority’s requirements whilst exercising your professional judgement at all times
- 11.
- 12. Developers ● Skilled, Passionate, Healthy, Focused,Disciplined ● Conferences, user groups, meet ups ● Read books, blogs, code ● Write code, Open Source contributions
- 13.
- 14. How to develop quickly (inthe short term)
- 15. ● Less testing ● Less planning ● Lesscommunication ● Don't improve tools / processes ● Overtime ● Outsource
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29. Visible Invisible Good FeaturesArchitecture Bad Defects
- 30.
- 31.
- 32. Visible Invisible Good FeaturesArchitecture Bad Defects Technical debt
- 34.
- 35.
- 36. Good idea ● You thinkyou'll be better off in the future ● The risk (interest) is manageable
- 38. Interest ● More user supportneeded ● Manual tasks ● Complete rewrite in future
- 39. Consequences ● Less time onnew features ● Higher cost of new features ● Harder to estimate new features
- 40.
- 42.
- 43.
- 44. We need torecognize 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
- 45.
- 46.
- 50. TDD ● Run every bitof code that you write, ASAP
- 51. Write a testwhen you fix a bug
- 53. Domain-Driven Design ● Model the domaincompletely in classes that don't touch the UI, database or framework
- 55. How do youkeep technical debt to a minimum?
- 56.
- 57. Refactoring ● Restructuring without changing behaviour ● Makesit easier to read, understand, test, change, add new features to
- 59. Refactoring ● Inject dependencies ● Eliminate dependencies ● Createinterfaces to type hint to ● Extract functions ● Rename ● Reduce cyclomatic complexity ● http://refactoring.com/catalog/
- 60. Estimating ● Estimates for newfeatures 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 ● Payingtechnical debt with interest takes more time than continual refactoring
- 62.
- 63.
- 64. ● Help you deliverfaster 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 isa balance
- 68.