Balancing
Technical Debt
and Clean Code
@dave1010
Dave Hulbert
@wearebase
@phpdorset
@dave1010
Dave Hulbert
istockphoto.com
tensionnot.com
shutterstock.com
Good things
●
Delivering fast
●
Clean code
Bad things
●
Technical debt
●
Delivering slow
Code of Conduct
Carry out your professional
responsibilities with due care and
diligence in accordance with the
Relevant A...
How to develop
quickly
Developers
●
Skilled, Passionate, Healthy,
Focused, Disciplined
●
Conferences, user groups, meet ups
●
Read books, blogs, ...
Projects
●
Good requirements
●
Good specifications
●
Fast feedback
How to develop
quickly
(in the short term)
●
Less testing
●
Less planning
●
Less communication
●
Don't improve tools /
processes
●
Overtime
●
Outsource
Technical Debt
Shipping code
before it's ready
Shipping code
without enough
architecture
Visible Invisible
Good
Bad
thetruthaboutcars.com
Visible Invisible
Good Features
Bad
uberhumor.com
flickr.com/dangelophoto1
Visible Invisible
Good Features
Bad Defects
wikimedia.org
Visible Invisible
Good Features Architecture
Bad Defects
amazon.com
mirror.co.uk
Visible Invisible
Good Features Architecture
Bad Defects Technical debt
Technical Debt
thisismoney.co.uk
Good idea
●
You think you'll be better off
in the future
●
The risk (interest) is
manageable
Interest
●
More user support needed
●
Manual tasks
●
Complete rewrite in future
Consequences
●
Less time on new features
●
Higher cost of new features
●
Harder to estimate new
features
bbc.co.uk
Complexity
Tests
●
Not comprehensive
●
Incorrect
●
Slow
We need to recognize that our job
isn't about producing more code in
less time, it's about creating
software that is stabl...
Invest in
architecture
Invest in
code
TDD
●
Run every bit of code that you
write, ASAP
Write a test when
you fix a bug
Domain-Driven
Design
●
Model the domain completely
in classes that don't touch the
UI, database or framework
How do you keep
technical debt to a
minimum?
Refactoring
wikimedia.org
Refactoring
●
Restructuring without
changing behaviour
●
Makes it easier to read,
understand, test, change, add
new featur...
Refactoring
●
Inject dependencies
●
Eliminate dependencies
●
Create interfaces to type hint to
●
Extract functions
●
Renam...
Estimating
●
Estimates for new features
need to include refactoring
– (if you don't want to increase
technical debt)
– Ref...
Debt is expensive
●
Paying technical debt with
interest takes more time than
continual refactoring
bonkersworld.net
Break the rules
●
Help you deliver faster in the
short term
●
Long term strategy
●
Disposable prototype
●
Just don't need to write clean
c...
Sprint vs Marathon
Sprint (example) Marathon (example)
Peripheral component (logs) Central component (DB)
Trivial (make a ...
Investment in code
is a balance
Thanks!
bitly.com/tech-debt-
feedback
@dave1010
Dave Hulbert
Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
Balancing Technical Debt and Clean Code
Upcoming SlideShare
Loading in …5
×

Balancing Technical Debt and Clean Code

725 views

Published on

Balancing technical debt and getting things done is one of the hardest problems we have. When should we write beautiful, elegant, clean code and when should we just hammer away blindly at the keyboard until it's done? This talk goes in to why this balance is so difficult and covers everything from estimations to refactoring and testing, with a focus on real world web apps.

Published in: Software
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
725
On SlideShare
0
From Embeds
0
Number of Embeds
56
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Balancing Technical Debt and Clean Code

  1. 1. Balancing Technical Debt and Clean Code @dave1010 Dave Hulbert
  2. 2. @wearebase @phpdorset @dave1010 Dave Hulbert
  3. 3. istockphoto.com
  4. 4. tensionnot.com
  5. 5. shutterstock.com
  6. 6. Good things ● Delivering fast ● Clean code
  7. 7. Bad things ● Technical debt ● Delivering slow
  8. 8. 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
  9. 9. How to develop quickly
  10. 10. Developers ● Skilled, Passionate, Healthy, Focused, Disciplined ● Conferences, user groups, meet ups ● Read books, blogs, code ● Write code, Open Source contributions
  11. 11. Projects ● Good requirements ● Good specifications ● Fast feedback
  12. 12. How to develop quickly (in the short term)
  13. 13. ● Less testing ● Less planning ● Less communication ● Don't improve tools / processes ● Overtime ● Outsource
  14. 14. Technical Debt
  15. 15. Shipping code before it's ready
  16. 16. Shipping code without enough architecture
  17. 17. Visible Invisible Good Bad
  18. 18. thetruthaboutcars.com
  19. 19. Visible Invisible Good Features Bad
  20. 20. uberhumor.com
  21. 21. flickr.com/dangelophoto1
  22. 22. Visible Invisible Good Features Bad Defects
  23. 23. wikimedia.org
  24. 24. Visible Invisible Good Features Architecture Bad Defects
  25. 25. amazon.com
  26. 26. mirror.co.uk
  27. 27. Visible Invisible Good Features Architecture Bad Defects Technical debt
  28. 28. Technical Debt
  29. 29. thisismoney.co.uk
  30. 30. Good idea ● You think you'll be better off in the future ● The risk (interest) is manageable
  31. 31. Interest ● More user support needed ● Manual tasks ● Complete rewrite in future
  32. 32. Consequences ● Less time on new features ● Higher cost of new features ● Harder to estimate new features
  33. 33. bbc.co.uk
  34. 34. Complexity
  35. 35. Tests ● Not comprehensive ● Incorrect ● Slow
  36. 36. 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
  37. 37. Invest in architecture
  38. 38. Invest in code
  39. 39. TDD ● Run every bit of code that you write, ASAP
  40. 40. Write a test when you fix a bug
  41. 41. Domain-Driven Design ● Model the domain completely in classes that don't touch the UI, database or framework
  42. 42. How do you keep technical debt to a minimum?
  43. 43. Refactoring wikimedia.org
  44. 44. Refactoring ● Restructuring without changing behaviour ● Makes it easier to read, understand, test, change, add new features to
  45. 45. Refactoring ● Inject dependencies ● Eliminate dependencies ● Create interfaces to type hint to ● Extract functions ● Rename ● Reduce cyclomatic complexity ● http://refactoring.com/catalog/
  46. 46. 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
  47. 47. Debt is expensive ● Paying technical debt with interest takes more time than continual refactoring
  48. 48. bonkersworld.net
  49. 49. Break the rules
  50. 50. ● Help you deliver faster in the short term ● Long term strategy ● Disposable prototype ● Just don't need to write clean code
  51. 51. 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
  52. 52. Investment in code is a balance
  53. 53. Thanks! bitly.com/tech-debt- feedback @dave1010 Dave Hulbert

×