Skip to content

A tech debt reading and resources list - to help diagnose, prevent and control tech debt.

License

Notifications You must be signed in to change notification settings

Hiberly/tech-debt-reading-list

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 

History

23 Commits
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

Tech Debt - Prevention, Diagnosis and Cure

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

🏁 Start here

What is tech debt

  • Ward Cunningham coined the term "tech debt".
  • Talks about history, motivation and common misunderstanding of the "debt metaphor" for refactoring.

Classifying Technical Debt

  • 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.

πŸŽ– Case Studies

Ticketmaster

  • Step-by-step guidance on how Ticketmaster assessed their technical debt over 12 months.

Stripe

  • Will Larson explains how Stripe use migrations to get away from tech debt.

A large bank

  • 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.

Paddy Power

  • Lianping Chen's article explains why the Paddy Power team decided to adopt Continuous Delivery, and explains the benefits and challenges involved.

β›” Prevention

🀝 Requirements

Creating a Product Canvas

  • 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.

Story Mapping

  • 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.

Joint Application Design

  • 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.

πŸ“‘ Infrastructure

DevOps 101

  • 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

πŸ›οΈ Architectural

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.

🎨 Design

What is design debt?

  • 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.

Marginal Brand Degredation

  • 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.

Design Systems

  • An enormous set of example design systems collated by Alex Pate
  • Covers components, voice and tone, designers kit and source code availability.

Primer Interface Guidelines

  • Repository to generate documentation for UI patterns and interaction guidelines.

πŸ’» Code

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

βœ… Testing

Test Driven Development

  • Kent Beck came up with the concept of Test Driven Development (TDD)
  • Test Driven Development is defined by writing tests before writing any functionality.

πŸ› οΈ Build

Continuous Integration

  • 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.

πŸ“ Documentation

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

🏚️ Versioning

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.

Writing good commit messages

  • You will default into messy commit messages. Chris Beams shows what good looks like.

πŸ₯ Remediation

πŸ” Post Mortems

PagerDuty Toolbox

  • 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.

πŸ’£ High Interest Debt First

'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).

🧭 Boy Scout Rule

The Boy Scout Rule explained

  • 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.

🧰 Tools

  • 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

Contributing

Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.

Authors

License

This project is licensed under the MIT License - see the LICENSE file for details

Sponsors

Hiberly Logo

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.

About

A tech debt reading and resources list - to help diagnose, prevent and control tech debt.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published