A tech debt reading and resources list. It contains lots of ways to diagnose, prevent and control tech debt.
This is a WIP! Please add any resources you find interesting by creating a fork and creating a pull request.
Table of Contents
- Ward Cunningham coined the term "tech debt".
- Talks about history, motivation and common misunderstanding of the "debt metaphor" for refactoring.
- Martin Fowler makes two disctions (1) prudent and reckless debt, and (2) deliberate and inadvertent debt. A classic
Identifying when Technical Debt needs action
- Henrik Kniberg argues that older tech debt is bad, whereas new tech debt is acceptable in order to build prototypes.
- Concept of a qualitative debt ceiling technique to manage the level of technical debt.
The Human Cost of Technical Debt?
- Erik Dietrick goes into depth for how technical debt can harm teams.
- There includes discussion on (1) unpleasant work (2) team infighting (3) atrophied skills (4) turnover and attrition.
- Step-by-step guidance on how Ticketmaster assessed their technical debt over 12 months.
- Will Larson explains how Stripe use migrations to get away from tech debt.
- Dave Nicollete covers a detailed case study, with costs, of resolving prudent-intentional debt.
- Costs of the cleanup and the business impact included.
Optimizely design debt approach
- Dave Rau explains how when Optimizely got to 50 UI issues, they decided to do something about it.
- The team ran a 'Polish Day' once a week, with a points system for designers to prioritize work.
- Lianping Chen's article explains why the Paddy Power team decided to adopt Continuous Delivery, and explains the benefits and challenges involved.
- Ellen Gottesdiener provides a canvas to convey what the product is, and how it is strategically positioned.
- The first part of the canvas comes before everything else and gives the context. It goes from vision through other high level areas such as revenue, competitors, and the innovation landscape.
- The second part of the template is used to explain product requirements.
- Jeff Patton invented the concept of Story Mapping (you can see a video of this process here)
- Flat product story backlogs are hard to understand - they are just a pile of features. By visualising an entire system with it can be much easier to spot opportunities or weaknesses, or indeed to work with other stakeholders in requirements gathering.
- Create a series of cards with big stories (activities) at the top, down to tasks and then sub tasks.
- This is a thorough run-through by the Project Management Institute for Joint Application Design. It gives guidance on how to run design sessions for multi-stakeholder requirements gathering.
- Bryant Son's simple guide that guides you through the basic setup to enable you to build you first pipeline
- Covers (1) CI/CD Tools (2) source control management (3) build automation (4) web app servers (5) code testing coverage
TODO: Add better DevOps resources here
Practical tips on Software Architecture Design
- Marco Bürckel gives a good 101 on how to architect a system, starting with what to do before you pick a software deign pattern, through to functional and non-functional requirements and iteration.
Understanding software design patterns
- Bryant Son provides detailed diagrams explaining different software patterns, including (1) Singleton (2) Factory (3) Observer, with code examples for each.
Software Architecture Patterns
- Mark Richards' book, fully available for free, gives an overview of (1) layered architecture (2) event-driven architecture (3) microkernel architecture (4) microservices architecture (5) space-based architecture.
- Within each section, there is a run through of the circumstances that are appropriate for each architectural type.
- An extensive run through by Michal Mazur, from his experiences at Kurt Geiger, where they had people drop out of the funnel because of inconsistent design.
- Just 1.6% is the difference in DNA between a gorilla and a human. Mark Boulton uses a powerful analogy to explain the importance of marginal brand degradation.
- An enormous set of example design systems collated by Alex Pate
- Covers components, voice and tone, designers kit and source code availability.
- Repository to generate documentation for UI patterns and interaction guidelines.
SOLID Principles of Object Oriented and Agile Design
- Bob Martin ('Uncle Bob') explains software design principles.
- This covers the principles of: Single Repository, Open Closed, Liskov Substitution, Interface Segregation, Dependency Inversion
- Kent Beck came up with the concept of Test Driven Development (TDD)
- Test Driven Development is defined by writing tests before writing any functionality.
- Martin Fowler's overview explains how Continuous Integration - where members of a team integrate their work frequently, usually daily by each developer - can ensure the codebase is more coherent and bugs are easier to find.
- The article covers the practices, but also the benefits and how to introduce Continuous Integration into the way a team works.
Continuous Delivery - a systemic review of approaches
- This paper represents a state of the art, based on peer-reviewed papers from 2004 to 2016, by Mojtaba Shahin, Ali Babar, and Liming Zhu.
- The paper identifies 30 approaches and associated tools, including succesful applications to both greenfield and existing codebases, with the issues and opportunities that continuous practices summarised.
Real life examples of great documentation
- Katrina Morales gives examples covering (1) providing answers fast (2) creating community through comments (3) great navigation (4) design (5) rich content.
Extreme Programming Documentation
- Ron Jeffries, one of the three founders of Extreme Programming, covers the documentation of (1) requirements (2) design (3) code (4) manuals.
The Eight Rules of Good Documentation
- This excerpt from Adam Scott's 'Collaborative Web Development' book, walks through not the "what" of documentation, but the "how".
Version control best practices
- A simple set of rules from Tobias Günther, the founder of Tower (a Git client) hat will help make sure the whole team can work with the commits that each developer makes.
- You will default into messy commit messages. Chris Beams shows what good looks like.
- PagerDuty have put together a completely all encompassing set of templates and an approach to the Post Mortem.
Language to use, understanding causation, and how to share
- Lindsay Holmwood discusses how a thoughtful approach to learning from failure is key.
- When to use "how" versus "what" versus "why".
- Confirmation and hindsight bias.
- Creating a safe culture to discuss failure.
'State of the Art - research summary'
- 38 research papers summarised found there isn't a distinct "best practice" that has become clear yet.
- Code and architecture are by far the two most focussed on areas, yet there are many more forms of debt (requirements, and tests, for example).
- Arun Sasidharan creates a great explanation of Bob Martin's rule.
- The premise is to create a culture of leaving the code in a better state than when you started.
- Continuous tracking of Tech Debt based on merges: Hiberly
- Code coverage, Cyclomatic complexity: Sonarqube
- Time to Interact: Yottaa
- Application security: Veracode
- Infrastructure performance: Splunk
- Scalability: SOASTA
Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.
- James Hawkins - Initial work - jamesefhawkins
- Tim Glaser - Editing - timgl
This project is licensed under the MIT License - see the LICENSE file for details
Hiberly prioritizes tech debt by grabbing feedback from developers after each merge.
You can then draw cool graphs of your code versus happiness / frustration to help explain the impact of refactoring.