Our Approach Dealing with Technical Debt
Pexels

Our Approach Dealing with Technical Debt

Attended a talk by Martin Fowler at the Xconf on ‘technical debt’ and this got me thinking about the initial situation we had in SPH.

‘Technical debt’ is a metaphorical term coined two decades ago by Ward Cunningham, and it refers to the degraded quality resulting from overly hasty delivery of software capabilities to users. In simpler terms, it means that ‘technical debt’ is a result of choosing an easy, quick and “unclean” solution to ship software to users as early as possible.

If you have a system that requires a new functionality you will see two ways to do it. Both with its pros and cons.

1: Write and deploy the code in a quick but unclean fashion (e.g. inefficient technical design, non-optimized code, insufficient testing, etc).

Pros: System gets shipped out of the door quickly

Cons: If further changes are required (most of the time), reworking will be a lot harder and almost impossible to implement. Stability of the software may be compromised

2: Clean up technical design and code quality (e.g. using descriptive naming, consistent coding style, readability, functionality, categorical sorting, etc)

Pros: Better quality thus stability, increases the ease of maintenance

Cons: Got to prioritize, more time is required to plan and test, with potentially added resources needed 

Choosing option 1 will most definitely incur technical debt. And like monetary debt, if technical debt is not repaid, it accumulates ‘interest’, which comes in the form of added time and effort for future development, making it harder to implement changes and reworks at a later stage.

With the shortening of disruptive cycles, businesses are forced to innovate quickly or perish. Innovation that involves technology usually results in new product innovations or new product feature innovations. Technical debt affects this need for change. As the debt builds up, and the need for change increases as the disruptive cycle shortens, the agility of a company is dramatically affected. This increases over time exponentially if old technical debts remain. 

The tricky thing about technical debt is that unlike money, it is difficult to quantify and measure it effectively. The interest repayment in technical debt correlates to the team’s productivity, which can arguably be a tough thing to measure.

Martin introduced 2 concepts and diagrams to explain how to best measure the need for great design implementation to tackle technical debt.

No alt text provided for this image

Chart 1:

There are 4 types of debt, categorized into a quadrant. The main difference is to identify whether the debt is reckless or prudent. Reckless usually means that teams have not considered technical debt, whilst prudent means that teams usually have no choice but to ship the product as quickly as possible and then deal with technical debt at later stages.

No alt text provided for this image

Chart 2:

In order to weigh the need for great design, the Design Stamina Hypothesis chart comes into the picture. The design payoff line is where the two lines intersect and in unwieldy circumstances, trading off design quality for time to market may be worth it (usually only in the short-term). Putting effort into design would in the long term be an enabler for speed – great design would improve the stamina of the project, allowing teams to go faster for longer. On the other hand, the problem with no-design is that by not putting in the initial effort into the design, the code base deteriorates and becomes harder to modify, and this lowers productivity, as shown via the gradient of either line in the graph above.

In most situations, we might not always have the luxury of time and resources to adopt the painstakingly tedious way of implementing great software design or repaying all the technical debt at once.

So how do we measure and prioritize which option to choose?

We are presented with three choices.

Option 1: We pay off the principal in one shot, which refers to the code base and having it overhauled or replaced.

Option 2: We continue paying interest rates, which would make the debt snowball beyond the point of no return.

Option 3: Choose the in-between, accept the fact that the principal cannot be repaid in one shot; gradually work your way up by paying back some principal and factoring interest for new features and enhancements.

In light of the available research and analysis available, my team and I have applied some of these best practices to resolve a couple of on-going challenges.

  1. We did a manpower planning exercise based on the debt we have, focusing on the need to instill greater rigor in building clean codes and prioritizing product features.
  2. Our product management team lead by our CPO, Gaurav Sachdeva, helped create a “True-North” list of product roadmaps and priorities.
  3. We showcased various manpower plans to Management. Engagement and buy-in were crucial as one of the options were to double the team size and include new capabilities. As a result, we achieved our objectives.
  4. Then comes the hard part which is a work in progress; hiring and retaining talents to fill these roles when the competition for talents is at its peak. How do we then make ourselves an attractive workplace? Aside from skating parks, glam office, and fluffy perks, we had to engage HR to develop a relevant job grade structure that provides staff with value add to their career paths, which will (hopefully) cycle back our way in the future. We also desire to facilitate open communication and positive feedback, thus creating open forums for our engineers to voice out their concerns and issues to acknowledge that they matter.

We have started to observe better governance leveraging good software engineering practices. Engineers are focusing on software architecture design and coding best practices. We have also introduced tools to improve code quality, automate software testing, monitor application performance, etc. However, a lot of coaching and training is required to fully equip our engineers with the necessary knowledge and discipline.

The engineering team also compiled a “True-South” list of all the technical tasks that must be carried out including clearing of technical debts, systems, and software upgrades, security compliance, technology monitoring, and experiments, etc. These tasks are prioritized with relevant product manager into the regular sprints.

A cadence for meetups was set. This included daily stand-up meetings, sprint review and retrospective meetings among the product teams. New discussion meetings included a product steering committee meet up, weekly huddles with our Deputy CEO (+his team) and monthly meetups with our English and Chinese editorial stakeholders.

Overall, this is just the beginning of our transformational journey and we have some ways to go, but the gears are in motion and the process has begun.

To conclude, sacrificing design for short-term gains will lead to more losses in the long-term, and even if you’re in a pressure cooker environment with a headcount freeze situation, it’s always best to give some thought to implementing some measure of great design in the project – even the best teams will have debt to deal with as a project goes on.

No alt text provided for this image


要查看或添加评论,请登录

Glen Francis的更多文章

社区洞察

其他会员也浏览了