Saturday, February 4, 2023
HomeSoftware DevelopmentBottleneck #01: Tech Debt

Bottleneck #01: Tech Debt

In its early days, a startup searches for product-market match. When
it finds one it seems to develop quickly, a part often called a scaleup. At this
time it is rising quickly alongside many dimensions: revenues, buyer,
headcount. At Thoughtworks, we have labored with many such scaleups, and our
work has centered on find out how to assist them overcome varied bottlenecks that
impede this progress.

As we have finished this work, we have observed frequent
bottlenecks, and discovered approaches to take care of them. This text is the
first in a sequence that examines these bottlenecks. In every article we’ll look
at how startups get into the bottleneck, normally by means of doing the suitable
issues which might be wanted early in a startup’s life, however are now not proper as
progress adjustments the context for tactics of working. We’ll spotlight key indicators
that the startup is approaching or caught within the bottleneck. We’ll then speak
about find out how to break by means of the bottleneck, describing the adjustments we have seen
that permit scaleups to achieve their correct potential.

We begin this sequence by taking a look at technical debt: how the instruments and
practices that facilitate fast experimentation of the product/market match
want to alter as soon as progress kicks in.

How did you get into the bottleneck?

The most typical scaling bottleneck we encounter is technical debt —
startups commonly state that tech debt is their most important obstacle to
progress. The time period “tech debt” tends for use as a catch-all time period,
usually indicating that the technical platform and stack wants
enchancment. They’ve seen characteristic improvement decelerate, high quality points, or
engineering frustration. The startup crew attributes it to technical debt
incurred resulting from a scarcity of technical funding throughout their progress part.
An evaluation is required to determine the sort and scale of the tech debt.
It may very well be that the code high quality is unhealthy, an older language or framework
is used, or the deployment and operation of the product isn’t absolutely
automated. The answer technique may be slight adjustments to the groups’
course of or beginning an initiative to rebuild elements of the applying.

It’s vital to say that prudent technical debt is wholesome and desired,
particularly within the preliminary phases of a startup’s journey. Startups ought to
commerce technical facets similar to high quality or robustness for product supply
velocity. This can get the startup to its first objective – a viable enterprise
mannequin, a confirmed product and prospects that love the product. However because the
firm seems to scale up, we’ve got to deal with the shortcuts taken, or it
will in a short time have an effect on the enterprise.

Let’s study a few examples we’ve encountered.

Firm A – A startup has constructed an MVP that has proven sufficient
proof (consumer visitors, consumer sentiment, income) for traders and secured
the following spherical of funding. Like most MVPs, it was constructed to generate consumer
suggestions moderately than high-quality technical structure. After the
funding, as an alternative of rebuilding that pilot, they construct upon it, maintaining the
traction by specializing in options. This is probably not a direct drawback
for the reason that startup has a small senior crew that is aware of the sharp edges and
can put in bandaid options to maintain the corporate afloat.

The problems begin to come up when the crew continues to deal with characteristic
improvement and the debt isn’t getting paid down. Over time, the
low-quality MVP turns into core elements, with no clear path to enhance or
substitute them. There may be friction to study, work, and help the code. It
turns into more and more tough to broaden the crew or the characteristic set
successfully. The engineering leaders are additionally very nervous in regards to the
attrition of the unique engineers and dropping the data they’ve.

Finally, the shortage of technical funding involves a head. The crew
turns into paralyzed, measured in decrease velocity and crew frustration. The
startup has to rebuild considerably, that means characteristic improvement has to
decelerate, permitting rivals to catch up.

Firm B – The corporate was based by ex-engineers they usually
needed to do the whole lot “proper.” It was constructed to scale out of the field.
They used the most recent libraries and programming languages. It has a finely
grained structure, permitting every a part of the applying to be
carried out with completely different applied sciences, every optimized to scale
completely. Consequently, it should simply be capable to deal with hyper progress when
the corporate will get there.

The difficulty with this instance is that it took a very long time to create,
characteristic improvement was gradual, and lots of engineers frolicked engaged on the
platform moderately than the product. It was additionally laborious to experiment — the
finely grained structure meant concepts that didn’t match into an current
service structure had been difficult to do. The corporate didn’t understand
the worth of the extremely scalable structure as a result of it was not capable of
discover a product-market match to achieve that scale of buyer base.

These are two excessive examples, primarily based on an amalgamation of varied
purchasers with whom the startup groups at Thoughtworks have labored. Firm A
bought itself right into a technical debt bottleneck that paralyzed the corporate.
Firm B over-engineered an answer that slowed down improvement and
crippled its capability to pivot shortly because it learnt extra.

The theme with each is an incapability to seek out the suitable steadiness of technical
funding vs. product supply. Ideally we need to leverage the usage of prudent technical debt to energy
fast characteristic improvement and experimentation. When the concepts are discovered to
be worthwhile, we must always pay down that technical debt. Whereas that is very simply
said, it may be a problem to place into follow.

To discover find out how to create the suitable steadiness, we’re going to study the
several types of technical debt:

Typical kinds of debt:

Technical debt is an ambiguous time period, usually thought to be purely
code-related. For this dialogue, we’re going to make use of technical debt to imply
any technical shortcut, the place we’re buying and selling long-term funding right into a
technical platform for short-term characteristic improvement.

Code high quality
Code that’s brittle, laborious to check, laborious to know, or poorly
documented will make all improvement and upkeep duties slower and can
degrade the “enjoyment” of writing code whereas demotivating engineers.
One other instance is a site mannequin and related knowledge mannequin that doesn’t
match the present enterprise mannequin, leading to workarounds.

A scarcity of unit, integration, or E2E assessments, or the unsuitable distribution
(see take a look at pyramid). The developer can’t shortly get confidence that
their code won’t break current performance and dependencies. This leads
to builders batching adjustments and a discount of deployment frequency.
Bigger increments are more durable to check and can usually lead to extra bugs.
Between modules (usually occurs in a monolith), groups doubtlessly
block one another, thus decreasing the deployment frequency and
rising lead time for adjustments. One resolution is to drag out companies
into microservices, which comes with it’s personal
— there could be extra easy methods of setting
clear boundaries inside the monolith.

Unused or low worth options
Not usually considered technical debt, however one of many signs of
tech debt is code that’s laborious to work with. Extra options creates
extra circumstances, extra edge instances that builders need to design
round. This erodes the supply velocity. A startup is experimenting. We
ought to all the time be certain to return and re-evaluate if the experiment
(the characteristic) is working, and if not, delete it. Emotionally, it may be very
tough for groups to make a judgment name, nevertheless it turns into a lot simpler
when you could have goal knowledge quantifying the characteristic worth.

Old-fashioned libraries or frameworks
The crew will likely be unable to benefit from new enhancements and
stay weak to safety issues. It is going to lead to a expertise
drawback, slowing down the onboarding of recent hires and irritating
present builders who’re pressured to work with older variations. Moreover, these
legacy frameworks are likely to restrict additional upgrades and innovation.

Sub-optimum third-party merchandise or instruments that require a number of
upkeep. The panorama is ever-changing, and extra environment friendly
tooling could have entered the market. Builders additionally naturally need to
work with probably the most environment friendly instruments. The steadiness between shopping for vs.
constructing is advanced and wishes reassessment with the remaining debt in

Reliability and efficiency engineering issues
This will have an effect on the client expertise and the flexibility to scale. We
need to watch out, as we’ve got seen wasted effort in untimely
optimization when scaling for a hypothetical future scenario. It’s higher to
have a product confirmed to be worthwhile with customers than an unproven product
that may scale. We’ll describe this in additional element within the piece on
“Scaling Bottleneck: Constructed with out reliability and observability in thoughts”.

Guide processes
A part of the product supply workflow isn’t automated. This might
be steps within the developer workflow or issues associated to managing the
manufacturing system. A warning: this will additionally go the opposite approach whenever you
spend a number of time automating one thing that isn’t used sufficient to be
well worth the funding.

Automated deployments
Early stage startups can get away with a easy setup, however this could
be addressed very quickly — small incremental deployments energy experimental
software program supply. Use the 4 key metrics as your information submit. It’s best to
have the flexibility to deploy at will, normally at the very least as soon as a day.

Data sharing
Lack of helpful info is a type of technical debt. It makes
it tough for brand spanking new workers and dependent groups to rise up to hurry.
As normal follow, improvement groups ought to produce concisely
written technical documentation, API Specs, and architectural
choice data. It also needs to be discoverable through a developer
portal or search engine. An anti-pattern is not any moderation and
deprecation course of to make sure high quality.

Is that basically technical debt or performance?

Startups usually inform us about being swamped with technical debt, however
beneath examination they’re actually referring to the restricted performance
of the technical platform, which wants its personal correct remedy with
planning, requirement gathering, and devoted sources.

For instance, Thoughtworks’ startup groups usually work with purchasers on
automating buyer onboarding. They could have a single-tenant resolution
with little automation. This begins off nicely sufficient — the builders can
manually arrange the accounts and monitor the variations between installs.
However, as you add extra purchasers, it turns into too time-consuming for the
builders. So the startup may rent devoted operations employees to set
up the client accounts. Because the consumer base and performance grows, it
turns into more and more tough to handle the completely different installs —
buyer onboarding time will increase, and high quality issues enhance. At
this level automating the deployment and configuration or shifting to a
multi-tenant setup will instantly influence KPIs — that is

Different types of technical debt are more durable to identify and more durable to level
to a direct influence, similar to code that’s tough to work with or quick
repeated handbook processes. The easiest way to establish them is with
suggestions from the groups that have them day-to-day. A crew’s
steady enchancment course of can deal with it and shouldn’t require a
devoted initiative to repair it.

How do you get out of the bottleneck?

The strategy that groups are taking to technical debt ought to come from
its technical technique, set by its leaders. It ought to be intentional,
clear, and re-evaluated over time. Sadly, we frequently see groups
working off historic instructions, creating future issues with out
realizing it. For an organization on this circumstance, a couple of alternatives
generally set off when to re-evaluate their present technique:

  • New funding means extra options and extra sources — this may compound
    present issues. Addressing present technical debt ought to be a part of the
    funding plan.
  • New product route can invalidate earlier assumptions and put
    stress on new elements of the programs.
  • A very good governance course of includes reevaluating the state of the
    expertise on an everyday cadence.
  • New opinions can assist keep away from “boiling frog” issues. Exterior assist, crew
    rotations and new workers will convey a contemporary perspective.

The slippery slope

How did you find yourself with a number of technical debt? It may be very laborious to
pinpoint. Sometimes it isn’t resulting from only one occasion or choice, however
moderately a sequence of selections and trade-offs made beneath stress.

Mockingly, on reflection, if one considers every choice on the level
in time at which it was made, primarily based on what was recognized on the
time, it’s unlikely to be thought of a mistake. Nevertheless, one
concession results in one other and so forth, till you could have a significant issue
with high quality. There may be generally a tipping level at which resolving the
tech debt takes extra time than growing incremental worth.

It’s laborious to get better and the scenario tends to snowball. It’s
pure for builders to make use of the present state as an indicator of what
is appropriate. In these circumstances, growing the brand new options will
lead to much more debt. That is the slippery slope, a vicious cycle
that sadly results in a cliff as the trouble to implement the following
characteristic will increase non-linearly.

Set a high quality bar

Many organizations discover it useful to have a set of requirements and
practices to which the corporate is dedicated that information technical
evolution. Understand that some technical practices are fairly
tough to realize, for instance steady supply; deploying
commonly with out affecting customers is technically difficult. Groups
usually have preliminary issues, and in response management could deprioritize
the follow. As a substitute we advocate the alternative, do it extra usually and
your groups will grasp the practices and kind robust habits. When the
robust time comes, moderately than dropping the follow, use the suggestions to
information future funding in crew functionality.

Blast Radius

We settle for that taking shortcuts is a needed a part of scaling the
enterprise. How can we restrict the blast radius, realizing that these shortcuts
will should be resolved, and even completely rebuilt? Clearly, we’d like a
technique that limits the influence to the enterprise. A method is to decouple
groups and programs, which permits a crew to introduce tech debt that’s
remoted and received’t essentially snowball as described above.

Top quality literature about decoupling is plentiful, so we received’t
try to clarify right here. We advocate focusing consideration on
microservices and area pushed design methods. Nevertheless, watch out
doing an excessive amount of too early, decoupling provides latency and complexity to your
programs, and selecting poor area boundaries between groups can add
communication friction. We will likely be writing about anti-patterns associated
to overcomplicated distributed architectures in future articles.

Product and Engineering Collaboration

If commerce off conversations aren’t balanced between enterprise technique,
product and engineering, technical high quality mostly degrades first,
and consequently product high quality finally suffers as nicely. Once you
search for the basis reason behind this bottleneck, it practically all the time comes down
to the steadiness inside the firm between enterprise, product and
engineering objectives. Lack of collaboration usually results in quick
sighted selections made in a vacuum. This will go each methods, chopping
corners in crucial areas or gold plating one thing that isn’t worthwhile
are equally seemingly.

  • The enterprise technique at any cut-off date ought to be clear and clear.
  • We empower crew leaders to make selections which profit the enterprise.
  • Product and Engineering ought to have an equal footing, belief in one another, and
    be keen to make commerce off selections primarily based on lengthy and quick time period influence to the enterprise.
  • Choices are made with knowledge – e.g. the present state of the technical platform,
    estimates, evaluation of anticipated worth and KPI enchancment, consumer analysis, A/B take a look at outcomes.
  • Choices are revisited when knowledge is refined or new learnings are found.

A tech technique to restrict technical debt influence

When pondering of methods for a startup, and the way it scales, we like
to make use of a four-phase mannequin to know the completely different phases of a
startup’s improvement.

Part 1


Prototypes – semi-functional software program to reveal product,
shifting to purposeful with rising curiosity

Part 2

Getting Traction

Ecosystem selections – cloud vendor, language selections, service
integration type

Exchange prototype software program for core programs

Setup preliminary foundations – experimentation, CI/CD, API,
observability, analytics

Set up the broad domains, set preliminary delicate boundaries (in

Part 3

(Hyper) Development

Create decoupled product groups managing their very own companies

Set up SLAs and high quality bar, linked to alerts round buyer
expertise of product

Set up platform groups centered on the effectiveness of product

Part 4


Reassess SLA and high quality bar centered on long run productiveness
and upkeep

Audit state of technical platform, sponsor initiatives in product
groups and create short-term tiger groups to repair largest technical debt

Rebuild or purchase capabilities for improved effectivity

Prepare groups on good technical high quality practices

How do you deal with the tech debt

It begins with clear info sharing how the
enterprise is doing, the present product route, metrics on the present
scaling capability, what prospects are saying in regards to the product and what
buyer help and ops are seeing. This info will permit
technologists to make knowledgeable selections. Sharing the information of the
present problem helps technologists to know why issues are being
addressed and measure their success.

There ought to be clear end-to-end possession of all merchandise and
their associated programs. As groups develop and take accountability for his or her
respective areas, there may be usually no clear possession for an end-to-end
journey, which leaves technical gaps that always develop into stuffed with
technical debt. As groups develop and tackle new duties, it turns into
more and more tough to seek out an proprietor for older code. Moreover,
with out possession, groups are much less incentivized to repair issues.

We have now to empower groups to repair issues — resolving technical debt ought to
be a part of the pure stream of product improvement. Engineers and product
managers want to barter the wholesome steadiness between tech debt vs.
performance with the suitable pragmatic mentality. It’s a part of a product
crew’s job to take care of and maintain technically wholesome merchandise, not one thing
finished as an after-thought. There ought to be an agreed course of to sort out and
monitor technical debt frequently. This requires laborious trade-offs amongst
engineering and product leaders to maintain a steady steadiness.

Designing your crew topology the suitable
approach will also be an element. For instance, suppose we frequently see
technical debt created in sure areas. In that case, it would point out
that the crew design is unsuitable, and there may be a platform or enterprise
functionality that wants robust possession and a spotlight.

Some metrics are highly effective — for instance, scanning for frequent
errors or measuring construct and deployment instances. The engineering
group ought to present self-service tooling into which groups
can shortly combine their programs. Metrics ought to be used as guides
for the crew to make selections about tech-debt moderately than for managers
to observe or incentivize. Skilled builders present worth by
decoding the accessible knowledge and grounding their intution in fact-based
qualitative info.

Whereas we consider in autonomous groups, an excessive amount of autonomy could be a drawback
and may end up in a chaotic technical panorama. There ought to be light-weight checks and balances such
as automated checks or architectural peer evaluate, which can assist implement
insurance policies and assist builders.

How your group chooses to deal with its tech debt relies on your
context. One frequent theme we’ve got seen throughout many organizations is the need
to “simply do one thing,” usually leading to a band-aid which quickly creates its
personal set of frictions. As a substitute, we’ve discovered that taking an iterative strategy
and letting the metrics mixed with present improvement exercise information the funding in resolving tech debt leads to
higher outcomes.



Please enter your comment!
Please enter your name here

nineteen + fifteen =

Most Popular

Recent Comments