a post aimed at budding tech-savvy folk who would like to understand the craft and pitfalls of building software that tiny bit more. And aimed at us, the software developers, just as a tiny reminder 😉
what is it?
Technical debt in software development is known as the implied cost of additional rework caused by choosing a quick and easy solution now instead of using a better approach that would take longer.
A relatable example, hopefully one to relate to, is monetary debt: If it is not repaid soon enough, it can accumulate ‘interest’, making it progressively harder to repay (i.e. implement positive changes) later on…
But let’s have a look at a small every day example in development, like this page of code in shambles: the picture bellow is an example of a project written in React . The speed and ‘getting it out there’ was clearly the priority here:
It could seem like it isn’t the worst yet: there are some defined styled-components, the logic is cut up into fairly small(ish) component parts…But after a closer inspection you could observe :
- business logic, styling, rendering of component parts — all are mixed in one big mush of a module (represented by the mix of colours and types of fonts). Not sure who would want to de-tangle this..
- the sound understanding of the program lives only in the short-term memory of one developers head .. Bus factor!* 🚎
- It is hard to read, comprehend and work with the program (especially for the developers who didn’t write it initially)
And here is that same module 🧩 , with some additional time taken to refactor and structure the code , after the software was ‘shipped’ and the technical debt issue addressed :
Again you will be quick to notice the immediately visible and improved segregation:
- modular — marked by green colour at the top , the imports;
- well separated business logics — blue colour in the middle
- dedicated styled rendering — yellow colour at the bottom
- it is much more readable and easier to comprehend: the eye catches sections of program
why should I care?
there are some definite benefits of addressing the technical debt
- software is less prone for breaking — lesser costs of fixing it ( which is longer than just addressing technical debt in the first place, because of the time it takes to ‘re-learn’ and understand the MESS of the thing, before fixing the bug. )
- workability — other developer can pick it up and work with legacy code with ease . A code-base less painful to work on makes the developer job more stable and, longterm , can result in better talent retention.( I can share from my personal experience that technical debt on legacy code in un-manned team was my personal key reasons for changing jobs)
- extended life (therefore investment) — well built software breaks less, therefore serves longer, therefore the investment that went into building it spreads thinner. Rome wasn't built in one day, imagine the cost of building it twice! thrice…
This wasn’t a deep-dive into technical debt, but hopefully a tiny understanding/a reminder of the huge implications our processes in development could have on software, businesses, careers, personal happiness , the list goes on my friends… 😉
*🚎 bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, from the phrase “in case they get hit by a bus”
