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.

1. Balancing
Technical Debt
and Clean Code
@dave1010
Dave Hulbert

2. @wearebase
@phpdorset
@dave1010
Dave Hulbert

3. istockphoto.com

5. tensionnot.com

6. shutterstock.com

7. Good things
●
Delivering fast
●
Clean code

8. Bad things
●
Technical debt
●
Delivering slow

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

11. How to develop
quickly

12. Developers
●
Skilled, Passionate, Healthy,
Focused, Disciplined
●
Conferences, user groups, meet ups
●
Read books, blogs, code
●
Write code, Open Source
contributions

13. Projects
●
Good requirements
●
Good specifications
●
Fast feedback

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

21. Shipping code
without enough
architecture

22. Visible Invisible
Good
Bad

23. thetruthaboutcars.com

24. Visible Invisible
Good Features
Bad

25. uberhumor.com

26. flickr.com/dangelophoto1

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

35. thisismoney.co.uk

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

43. Tests
●
Not comprehensive
●
Incorrect
●
Slow

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

45. Invest in
architecture

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?

56. Refactoring
wikimedia.org

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

68. Thanks!
bitly.com/tech-debt-
feedback
@dave1010
Dave Hulbert