Real-World Maintenance Costs

Costs of systems grow exponentially after the initial development project!

IT Budget Allocations

Cost of enhancement & maintenance 2X over new development.

Gartner 2003

What is Technical Debt?

  • When development teams take shortcuts on quality
    • Readability & coding standards
    • Automated tests
    • Refactoring
    • Domain Modeling

Technical Debt

Technical Debt

Technical Debt

Technical Debt

Velocity of Team with Technical Debt

Paying Back Your Technical Debt

5 Practices You Can Adopt Now

Savings Through Good Engineering Practices

Economic life of product gets extended.

Velocity of Team with Low Technical Debt

[//]: # (---

title: Some Basic Software Engineering Practices...

Software Engineering takes a lifetime to learn, but here are a few practices you can apply now.

)

1. Refactor Mercilessly

  • While solving a problem, it's ok to temporarily disregard code quality & design.
  • After problem is solved, don't go on to the next one until you clean up your code.

1. Refactor Mercilessly

Boy Scout Principle

"Leave the campsite cleaner than you found it."

2. Practice Test-Driven Development

  • Refactoring is safe only with comprehensive unit tests.
  • If programmers don't write their tests first, they will neglect to write their tests after.
  • Code is likely difficult to test in test-after.
    • TDD guides design.
  • Managers & team leaders should not accept code unless proven to work through unit tests.

2. Practice Test-Driven Development

Uncle Bob's 3 Rules of TDD

  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

3. Obsess on Readability

  • The 3-Second Rule

    If your teammate cannot understand your code in 3 seconds, rewrite it.

3. Obsess on Readability

Recommended Reading:

Clean Code

by Robert C. Martin ("Uncle Bob")

4. Practice Domain-Driven Design

  • Your code should reflect the domain!
  • Use a "Ubiquitus Language" with your stakeholders.
  • Your code is the repository of the team's understanding of the domain.
  • Domain Model should hold all business logic.
    • Not "Anemic Domain Model".

4. Practice Domain-Driven Design

Recommended Readings

5. Be a Scholar of Coding Practices & Design

  • Read every book and article you can get your hands on regarding coding practices and design.
    • Read Martin Fowler's books, blog posts, and books he's edited or endorses.
  • Knowledgeable developers write 1/10 - 1/100 of the code of ordinary developers, & their code is easy to change and maintain.

5. Be a Scholar of Coding Practices & Design

Recommended Readings

Paying Back Your Technical Debt

  1. Refactor Mercilessly

  2. Practice Test-Driven Development

  3. Obsess on Readability

  4. Practice Domain-Driven Design

  5. Be a Scholar of Coding Practices & Design

orangeandbronze
careers@orangeandbronze.com