What is technical debt?
Technical debt is the cost incurred when developers cut corners in order to prioritise the speedy delivery of a piece of functionality or a project over good quality code. Teams may reason that ‘Speed is the priority now, we can come back to these inefficiencies at a later date when we have time!’ This time often never comes, and the technical debt accumulates interest and increases software entropy (read, A Gradual Decline Into Disorder).
There are two types of technical debt - planned technical debt which occurs when teams knowingly cut corners in order to deliver a fast albeit imperfect product, and unintentional technical debt which happens by accident, often due to poor management, or a developers’ lack of understanding surrounding the requirements or lack of technical ability to meet such requirements.
As time goes by, the problem grows as new code is built upon the earlier but poorly written code. Slowly but surely the debt accumulates and the problem is too embedded and it’s too time consuming or costly to eradicate. An accumulation of poor code can cause developers to lose their commitment to maintaining standards and writing clean code at all times. Eventually, the problem will catch up with them.
The true cost of inheriting technical debt
Most developers, at some point in their careers, will have to deal with the consequences of technical debt. But what are the true, day to day effects of such debt? Technical debt will result in a backlog of requirements necessary to clean up the code and it will be incredibly challenging for new developers to pick up and continue on a project. Issues include high code complexity, lack of integration or automated tests, duplicated code or duplicated modules... to name a few! It will become increasingly hard to work on new features or maintain current ones and build times will be far slower. In short, the time and effort required to decipher and manage poor quality code will drain your productivity and seriously impede your ability to deliver value in the long run.
You’re considering a new job, but how can you possibly know if you’re likely to inherit technical debt?
You’re interviewing for a job, and as your potential employer starts talking about their projects your mind starts wondering ‘what kind of code am I going to inherit?’ The reality is, a potential employer is unlikely to confess if their code base is in utter chaos. So apart from outright asking if you can analyse their code base before you even consider a position with them, how can you possibly know what to expect? You don’t want to risk waiting until you start a new role, only to dive in and discover what a complete mess it is, so here are some tips to help you gauge (to a certain extent) what state it’s in before you make any big decisions.
Ask the right questions during the interview
Heard of the Joel test? It’s a set of questions used to assess the quality or standards of an organisation’s development team (www.joelonsoftware.com). You could use this or you could prepare your own questions to assess an organisations’ coding practices. Questions could include:
How would you describe your code complexity?
What source control management tools do you have in place?
Do you have a zero defect policy?
How much do you invest in new software or tools?
What’s your testing process?
Are you committed to continuous integration?
What deployment processes do you have in place?
Is it common to write new code while bugs or defects are known to exist?
What’s the single biggest issue or problem facing the team/company and what is currently being done to address it?
Read the room. Depending on the rapport established between yourself and your interviewer/s you may feel comfortable enough to simply ask outright what their situation is relating to technical debt. Some interviewers may view this as a taboo subject and put their guard up (read into that what you will), whereas others may take it as a sign that you're conscientious and care about code quality. As long as you are polite and respectful, it shouldn’t be an issue to ask - after all, changing jobs is a big step, you have the right to ask all the necessary questions in order to assess if it’s the right company or role for you.
You may ask questions such as:
How do you measure technical debt?
In the last 6 weeks has the amount of technical debt increased or reduced?
Do you allocate time to paying back technical debt or include time in your development cycles to fix issues?
Does TD specific work make it into the product backlog?
Use your intuition and read between the lines
There’s usually a lot of information to take onboard during an interview but listening carefully and reading between the lines can pay dividends. Often an interviewer will say certain things (or avoid certain topics) which will offer valuable clues into what their environment is really like. This may include information relating to their coding practices or deployment process, their time to market or their testing processes. Listen carefully.
Do your research
A useful indicator of technical debt is user feedback. Ask your potential employer what their customer feedback is like, or do your research and see if you can find some reviews if the company produces B2C software.
Engage in a spot of networking
Another indicator of the level of technical debt is a conscientious development team, so if you get the opportunity to meet the current team then grab it with both hands. By getting to know the current team either in their workspace or outside of work and engaging in conversations, you will gain valuable insight and get an overall feel for whether they’re happy and enjoying their work. Perhaps you know people in your circle who used to work there or you know someone who knows someone - it’s ok to ask around. Spend some time on LinkedIn or visit the developer community sites they’re part of and see what they’re posting about - are they enthusiastic about the projects they’re working on or posting ranty threads about blockages and delays?
Deny or accept
To conclude, when it comes to software development technical debt is all but inevitable, in fact, some may say it’s a necessary evil as trade-offs (speed v. perfection) so often have to be made. And it’s not always a bad thing - as a developer you will deal with technical debt regularly and you will know better than anyone how to prevent it and manage it.
By asking the right questions at the interview stage and getting to know the people you’ll potentially work with, you should get a good feel for the practices they adhere to and the standards they maintain. Are they honest and open communicators? Is TD addressed in regular stand-ups? Are there frequent feedback loops? Do they pivot based on validated learning? Is it a solid team where everyone assumes responsibility for TD and makes a conscious effort to pay off the debt?
Make a judgement as to whether the technical debt is of the inevitable and manageable kind or whether it’s the kind that will have you banging your head against your monitor within your first week.
At Forward Role you’ll find genuine industry experts who care passionately about delivering for their clients and candidates. If you're a candidate, we'll treat you the way we'd like to be treated when making an important life decision like moving jobs. If you're a client you can expect exceptional delivery and communication as a matter of course. But don't just take our word for it. We have over 100 five star ratings and reviews on Google and you can read some of our testimonials and case studies here.
Contact us now!
Call 0161 914 8499