Maintenance Cost Estimates

Owned by Diana Huang
Jan 21, 2022
2 min read

Assumptions:

  • Code that’s not being actively developed but that we need to keep working.

  • This is just a minimum, there are other benefits of removing code.

  • The cost of maintenance goes down the closer it is to being DEPRed.

  • There is a cost of confusion as a thing becomes less and less standard that is not captured here.



Next Steps:

  • Validate by calculating minimum maintenance across all edX github repos.



Types of deprecations:

  • Small service( ~10 weeks/year)

    • ASSUMPTIONS

      • Size of service: 200 KB python code.

    • Django Upgrades ( 3 days/year)

    • Python Upgrades (2 days/year)

    • Monitoring for breakage. (2 days/year)

    • Renovate PRs ( 2 weeks/year)

    • “make upgrade” PRs ( 2 weeks/year)

    • Flaky test diagnosis ( 1 day/year)

    • Deployment pipeline maintenance and troubleshooting (1 week/year)

    • OSPR review ( 2 weeks/year )

    • Security issue responses ( 2 days/year)

    • Writing and updating documentation ( 1 day/year)

    • Accessibility fixes (1 day/year)

    • CI/Release Tooling Maintenance( 1 week/year)

      • Updating test matrices.

      • Release to Production

      • Moving to new test runners(travis -> gh actions)

      • Updating usage of public actions.

  • Python Library/package( ~7 weeks/year)

    • ASSUMPTIONS

      • Size of Library/Package: 200 KB (including config and repo overhead)

    • Django Upgrades (3 days/year)

    • Python Upgrades (2 days/year)

    • Monitoring for breakage. (1-3 days/year based on app cohesion)

    • “make upgrade” PRs (2 weeks/year)

    • Flaky test diagnosis (1 day/year)

    • OSPR review (2 weeks/year )

    • Security issue responses (2 days/year)

    • Writing and updating documentation (1 day/year)

    • CI/Release Tooling Maintenance( 1 week/year)

      • Updating test matrices.

      • Release to PyPI

      • Moving to new test runners(travis -> gh actions)

      • Updating usage of public actions.

  • JS Library/Package( ~4 weeks/year)

    • ASSUMPTIONS

      • Size of Library/Package: 50 kb

      • Not Paragon because it’s our design system and needs more regular maintenance.

    • Paragon/React/Node upgrades (1 week/year)

    • Renovate PRs (2 days/year)

    • OSPR review ( 1 days/year)

      • This will change as MFEs become default.

      • As we add a pattern for front-end extension points.

    • Security issue responses (1 week/year)

    • Writing and updating documentation (3 days/year)

    • Accessibility fixes (0 days/year - these mostly happen in Paragon and MFEs)

    • Bug fixes & regression tests (1 week/year)

  • MFE (~ 5 weeks/year)

    • ASSUMPTIONS

      • Size of MFE: 200 KB 

    • Paragon/webpack/React/Node upgrades (1 week/year)

    • Renovate PRs (2 days/year)

    • OSPR review ( 2 days/year)

      • This will change as MFEs become default.

      • As we add a pattern for front-end extension points.

    • Security issue responses (3 days/year)

    • Writing and updating documentation (1 day/year)

    • Accessibility fixes (3 days/year)

    • Bug fixes & regression tests (1 week/year)

    • Monitoring for breakage. (2 days/year)

    • Deployment pipeline maintenance and troubleshooting (3 days/year)

    • CI/Release Tooling Maintenance( 2 days/year)

      • Updating test matrices.

      • Release to Production

      • Moving to new test runners (travis -> gh actions)

      • Updating usage of public actions.

  • Block of code in a larger service/package (~5-6 weeks/year)

    • ASSUMPTIONS

      • Size of code/package: 150 KB

    • Django Upgrades (3 days/year)

    • Python Upgrades (2 days/year)

    • Monitoring for breakage. (1-3 days/year based on app cohesion)

    • “make upgrade” PRs (2 weeks/year)

    • Flaky test diagnosis (1 day/year)

    • OSPR review (2 weeks/year)

    • Security issue responses ( 2 days/year)

    • Writing and updating documentation ( 1 day/year)

    • Accessibility fixes (1 day/year)