Technical Debt: Building it up to Burn it Down

Presented at Path to Agility 2018

Transcript

1. Technical Debt Building it up to burn it down
2. Who am I? Kyle Jenkins Senior Consultant, Software Engineer 10 Years in IT, Full Stack, Agilest Video Gaming, Anime speakerdeck.com/kjenkins19 kyle.jenkins@improving.com Twitter: @kjenkinsdev TLC Slack: @kyle.jenkins https://techlife-columbus-slack.herokuapp.com/
3. Quick Exercise • Write down up to 3 pieces of technical debt you would like to remove or fix right now.
4. What is Technical Debt? • Any entity which – Generates less value than it produces. – Can be modified to generate additional value. • Common Examples – Dead Code, Legacy Code – Out of date documentation – Processes
5. The Debt Chart Cost Value
6. What is Value? • What value can be measured?
7. Measuring • Focus on the $ – Time: $100/hour – Translate directly to more features • More Advanced: – What is the value on culture? – Risk Assessment
8. The cost of tech debt: Worst Case Scenario (Case Study) Knight Capital Group: $440 Million • https://www.infoq.com/news/2017/02/dead-code
9. Causes: Code • Rush for time, Deadlines • Poor Development Environment • Lack of experience – Poor code structure – Unreadable code – Lack of GOOD tests • Simultaneous Projects • A/B Testing • I didn’t know it already existed
10. Causes: Micromanagement as a Solution • Lack of or loss of trust • Once created, very difficult to remove
11. Test Driven Development Mindset Run existing test Cases Define new test cases The work is done Clean up
12. Test Driven Development Mindset Run existing test Cases Define new test cases The work is done Clean up Releasable
13. TDD Mindset: Refactor first Update what I can reuse For the current feature Run existing test cases Define new test cases The work is done
14. Development Environment • How fast can you: – Identify broken code? – identify dead variables? – go from a broken test to the related code? – see code coverage? – identify broken code standards? – extract new classes or methods? – identify usages of any entity? • Variables, Functions, Classes, etc. – see changes after writing code? – see real warnings and errors? – run duplicate code analysis? – identify code complexity? • .1, 1, 5, 10 Second Limits -XKCD
15. Utilize an IDE Can Provide: • Immediate feedback • Fast changes based on standard coding patterns If an IDE cannot comprehend your code: • The new guy can’t either • Reinforce poor standards on a global level
16. Development Environment
17. Workflow Processes
18. Workflow Processes
19. Workflow Processes
20. Signs of Blocked Development Processes • Temp Files • To do comments • Dead code comments
21. Signs of Hazardous Micromanagement Bad • Permission Instead • Forgiveness, w/follow up • Single Person Accountable • Dictation • Every Individual Accountable -> Team Accountability • Coaching
22. The cost of Micromanagement Self Managed Team
23. The cost of Micromanagement Self Managed Team
24. Documentation, just like code… • Has defined update processes, which can be blocked • Living, ever changing with the needs of the team/business • Should keep under version control • Delete Dead Documentation • Improves with Experience • Should be tested! • Excellent summary from Keith Wedinger https://jkwuc89.github.io/presentations/
25. The Kiss/Curse: A/B Testing Kiss • Assists the business in making valuable decisions Curse • Requires two sets of code, one of which will be dead code in the near future
26. The Kiss/Curse: A/B Testing Variety of ways to perform this testing • 3rd Party systems, external of the current code base – Determine value without interfering with current code base: no tech debt – Dependencies on current interface, and simple changes can break the test
27. The Kiss/Curse: A/B Testing Variety of ways to perform this testing • Internal flags – Both code bases exist at once: tech debt incoming – Technical planning up front to separate out any code associated with the test. – Include the removal of either one as part of the cost of the project.
28. The Kiss/Curse: A/B Testing Variety of ways to perform this testing • Utilize Git: More than one release branch – All updates while A/B test is live must function on both the primary code base, as well as property the test branch. This generally means “locking” some code so it cannot be modified during the test – Really simple from a code perspective to either succeed or fail the test. No tech debt. – Migrates most of the work to the operations teams.
29. Summary • Focus on ways to speed up the currently worked on feature. During, not after. • Let the team create solutions, instead coach them to focus on the root cause. Measure outcome. • Draw out your current process. Look for blocks which may encourage poor standards in quality.
30. The End: Questions? Kyle Jenkins Senior Consultant, Software Engineer 10 Years in IT, Full Stack, Agilest Video Gaming, Anime speakerdeck.com/kjenkins19 kyle.jenkins@improving.com Twitter: @kjenkinsdev TLC Slack: @kyle.jenkins https://techlife-columbus-slack.herokuapp.com/