Mark Niebergall presented on reducing technical debt by avoiding adding new debt, paying off existing debt through a repeating process, and tips on when to refactor code versus initiating a rewrite. He defined technical debt as consequences of poor design and architecture that are incurred knowingly and inadvertently. Examples of debt include unused code, outdated technology, and overcomplicated code. Sources of debt include changes to libraries, frameworks, and inexperience. Paying off debt requires identifying issues, prioritizing work, and making improvements over time through consistent effort.

1. Reduce Your
Technical Debt
Mark Niebergall - https://joind.in/talk/a3f07

2. Thank You Sponsors

3. About Mark Niebergall
● PHP since 2005
● Masters degree in MIS
● Senior Software Engineer
● Drug screening project
● UPHPU President
● SSCP, CSSLP Certified and SME
● Drones, fishing, skiing, father, husband

4. UPHPU
● 3rd Thursday of each month in Lehi
● PHP and related topics
○ Friday 6pm OpenWest review
○ August - Git
○ September - PHP TestFest
○ October - Defensive Coding
● Networking, community
● Pizza, pop, dessert, swag

5. About Mark Niebergall
● German
● Ancestry.com: nickname for someone who
habitually failed to repay his debts

6. Reduce Your Technical Debt

7. Reduce Your Technical Debt
● Definition
● How it is introduced
● Impact on a project
● Avoid adding
● Paying off existing debt

8. Audience Survey
● Roles on projects
● Languages used

9. Disclaimer
● PHP technologies
● Concepts apply to other languages and
projects

10. Definition

11. Definition
● Metaphor coined by Ward Cunningham
● Explained further by Martin Fowler, others

12. Definition
● Consequences of poor design, architecture
● Prudent vs reckless
● Incurred knowingly and inadvertently
● Work needed to complete job properly

13. Examples

14. Examples
● Unused code (dead wood)
● Old versions
● Dated technology
● Deprecated functionality

15. Examples
● Buggy code
● Overly complicated code
● Insecure code
● “Smelly” code

16. Examples
● Doesn’t meet requirements
● Insufficient features
● No documentation
● No unit tests

17. Examples
● Incomplete coding standards
● Missing database constraints
● Missing validation
● Tightly coupled code

18. Clearance Rack
● Food about to expire
● Questionable dairy and bread
● Items that have been sitting on the shelf a
little too long

19. University Bid Sales
● Aging computers and hardware
● Obsolete items
● Never opened items
● Broken items needing repair or parts
● Piles of cables and adapters

20. The Problem

21. The Problem - Updates
return a + b

22. The Problem - Updates
return (a + b).toFixed(2)

23. The Problem - Updates
if ( !isNaN(parseFloat(a))
|| isFinite(a)
|| !isNaN(parseFloat(b))
|| isFinite(b)
) {
throw “Not a number”;
}
return (a + b).toFixed(2)

24. The Problem - Files
index.html
stuff.js
morestuff.js
moreawesomestuff.js
utilities.js
core.js

25. The Problem - Database
Table: person
Columns: name, address, address1, city, state,
zip, phone, phone2, phone3, email, email2,
address_mailing, address1_mailing,
city_mailing, state_mailing, zip_mailing,
create_timestamp_string, …

26. The Problem - Database
Table: thing
Columns: name, description, image,
what_it_does, hours, location, cost, time,
owner, obscure_field, ts, sd, or, qa, ei, num, +
50 more columns

27. The Problem - Security
$sql = “SELECT * FROM big_table WHERE
something = “ $_POST[‘from_user’];
$result = mysqli_query($sql);

28. The Problem - Architecture
$value = [
‘some_key’ => [
‘another_key’ => [‘maybe_key’ => ‘alice’, 1 => ‘super awesome’],
‘questionable’ => [‘bob’, ‘cat’ => ‘kittens’, ‘mixed’ => new stdClass]
];

29. Sources of Technical Debt

30. Sources of Technical Debt
● New versions of libraries
● New versions of languages
● New versions of frameworks

31. Sources of Technical Debt
● Inexperience

32. Sources of Technical Debt
● Architecture changes

33. Sources of Technical Debt
● Time
● Resources
● Scope creep

34. Sources of Technical Debt
● Ignorance
● Misunderstanding of requirements
● Understanding of project

35. Sources of Technical Debt
● Unwillingness
● Lack of motivation

36. Impact

37. Impact
● Increased time to deliver new features
● Increased time to maintain application
● Increased time paying off debts
● Increased code complexity

38. Impact
● Software brittleness
● Software bloat
● Software rot
● Magic in application

39. Avoid Debt

40. Avoid Debt
● Avoid excessive debt
● Minimize risk
● Stay within means
● Use available resources
● Iron Triangle: Scope, Resources, Time

41. Avoid Debt - Operational
● Planning
● Requirements gathering
● Analyze project
● Documentation
● Acceptance tests

42. Avoid Debt - Technical
● Use a framework
● Be open to new technologies

43. Avoid Debt - Technical
● Package Manager
● Move 3rd party library out of project code
● Keep libraries, software up-to-date
● “Life is too short for old software” - Sebastian
Bergmann

44. Avoid Debt - Technical
● Unit tests
● Loosely coupled code
● Code reusability
● Reduce code complexity
● Leverage language features

45. Avoid Debt - Technical
● Static code analysis tools
○ Automated way to check code health
○ Unit test coverage
○ Coding standards
○ Unused code
○ Design patterns
○ Metrics
○ Methods doing too much

46. Avoid Debt - Technical
● Dynamic code review
○ Review by a human
○ Security reviews
○ Architecture
○ Linked functionality
○ Business rules
○ Functional bugs

47. Avoid Debt - Technical
● Continuous integration tools
● Configuration management tools

48. Avoid Debt - Technical
● Code reviews and feedback
● Coding standards
● Design patterns
● General best practices

49. Paying off Debt

50. Paying off Debt
● My experience with a big project
● Included PM, developers, devops, DBAs,
system administrators, QA, IT leadership
● Buy-in from upper management
● Application is faster, more stable, more
secure, modernized, easier to maintain

51. Paying off Debt
● Identified pain points
● Created epics
● Set priorities
● Defined user stories

52. Paying off Debt
● Assigned work, ownership
● Regular reporting as a team
● Regular reporting to management

53. Paying off Debt
● Defined goals for quarters, years

54. Paying off Debt
● Data migration out of database and into
cloud storage
● Data consolidation
● Data restructuring

55. Paying off Debt
● Adding middleware
● Framework upgrades
● Software upgrades
● Library upgrades

56. Paying off Debt
● Major overhauls in painful areas

57. Paying off Debt
● Moving processes to queue manager
● Cleaning up technology stack

58. Paying off Debt
● Security updates
● Auditing improvements

59. Paying off Debt
● Work spread out over time
● Measurable successes and milestones
● Very successful and still ongoing

60. Paying off Debt
● Make a plan
● Set goals
● Stay inside your budget

61. Paying off Debt
● Consistency
● Pay off some debt each sprint or regular
interval

62. Paying off Debt
● Repeating process
○ Identify debt
○ Make a plan
○ Take action

63. Taking on Debt

64. Taking on Debt
Four Rights
● Reason
● Time
● Terms
● Amount

65. Professional Development
● Participate in local user groups
● Find experienced mentors
● Attend conferences
● Read blogs
● Learn

66. Rewrite vs Refactor

67. Rewrite
● New project to replace current solution

68. Rewrite
● Sustainability of current solution is critical
● Large effort
● Long term benefits, not short
● Explore available technologies
● Prevent excessive new debt
● Higher risk of failure

69. Refactor
● Replace pieces of project in-place

70. Refactor
● Break effort up over time
● Results both short and long term
● Prioritize what to rework first
● Lower risk of failure

71. Rewrite vs Refactor
● Sustainability of current solution
● Level of effort
● Short and long term benefits
● Feasibility
● Technology stack
● Team capabilities

72. Review

73. Technical Debt
● Metaphor
● Reduce your debt
● Pay off debt using repeating process
● Tools available for your project
● Apply understanding to improve architecture

74. Questions?
● https://joind.in/talk/a3f07

75. References
● Ancestry.com http://www.ancestry.com/name-origin?surname=niebergall
● Ward Cunningham https://www.youtube.com/watch?v=pqeJFYwnkjE
● Martin Fowler http://martinfowler.com/bliki/TechnicalDebt.html
● David Laribee https://msdn.microsoft.com/en-us/magazine/ee819135.aspx
● Mark Noneman https://www.youtube.com/watch?v=cb5fkftdD9k