Johnny Butler

April 22, 2021

Technical Debt & Staff Training

Problem

Within a start up resources are generally stretched and it’s accepted that best practices are overlooked in certain situations in order to get a fix/feature out the door. This leads to the build up of technical debt that inevitably needs to be paid back, normally when you least want/need to. Another item that generally gets overlooked is staff development/training. Business demands generally mean producing the same tried and tested solutions rather than comparing the approach of a new technology/technique that may do the same job better. This new tool/technique may add another weapon to the armoury for use going forward. These are just some of the experiences I have had working within the start up and observed from speaking to colleagues in similar environments.
 

Solution - Daily Code Quality Challenge

As a tech lead in a recent start up I implemented a CQC(code quality challenge) to address the problems mentioned above. We send out a daily CQC via email first thing in the morning and each developer is to devote the first couple of hours of the day to this task. It takes priority over everything else except urgent live bug fixes. 
The challenge  structure is typically:

  1. Describes a problem area within the current codebase and what the impact is.
  2. Proposes a new technique/tool/best practice/design pattern to address the problem.
  3. Provides an example of how the approach in 2 resolves the problem in 1.
  4. The CQC challenges the participant to:
    • identify a problem similar to 1 within the existing application.
    • Challenges the participant to implement a solution based on 2.
  5. A PR is generally produced once the challenge is attempted.
  6. The PR is reviewed/discussed with various trade-offs.
  7. Some PRs make it into the working codebase, some don't.

What you end up with is an area within your project management system that explains a common problem within your software development lifecycle and a CQC solution to tackle it. This comes with various discussions between the team members about the relevant trade-offs. There should also be some PRs with code examples so the next time the challenge is undertaken there is something to build on. New/existing team members can revisit as and when needed.
 

Key Benefits

Staff Assessment -
  • Identify which team members know the fundamentals. 
  • Identify which team members can apply the fundamentals(some know the theory but can't execute).
  • Identify which team members can apply the fundamentals specifically to your tech needs(this is what you ultimately want).

Staff Development – Team members get to learn/practice new tools/techniques needed within the software development life cycle. This is done on company time so the employee feels the business cares about each individual’s personal development.

Collaboration – Team members get to collaborate which builds up relationships within the organisation. Junior developers get to see how a senior developer approaches a specific problem and ask questions. Less daunting than sending a direct request.

Company Standards - Coding standards/techniques are documented, you now have an area to point to when you want X done in a certain way, great for new hires.

Code Quality – Code quality is improved which is good for the business and the end users.

Technical Debt – Technical debt is tackled on an ongoing basis meaning less chance of a big rewrite to certain areas of the system. There is also less chance of incurring technical debt if the best practices/tools/techniques/design patterns are known before implementing a particular solution. The developer is more likely to choose the best approach over time.
 

CQC Example

An example of a CQC might be something like the below:

  • Can you identify an area within the application that violates the REST architecture and propose a more restful approach?
  • Can you implement the more RESTful approach via a code change and PR?
  • Can you use TDD for the new RESTful approach?

This challenge will include a code sample where REST is not adhered to. The challenge will then show the same code changed adhering to REST or another example that shows a REST approach so the participant can see what the end requirement is.