Technical Debt

Regular readers (do I actually have any, I wonder?) of my blog may be wondering why I’ve not posted any new content for the last few weeks. First off, let me apologise for this. Secondly, let me explain why: I’ve been busy… in my new job! That’s right, ladies and gentlemen, everyone’s favourite evil one has finally found himself employment again.

I am now Head of Engineering & Information Technology at a mobile media software company, which specialises in real-time bidding for mobile media advertisements. I actually interviewed for a Senior Software Engineer position but, somehow, bagged the managerial role. I’m still not quite sure how one turned into the other but, basically, the company needed to fill both roles and I just happened to have the right level and type of practical experience in setting up and implementing engineering best practice and process so they offered me the choice of either role. Of course, I took the head role and I am not complaining 🙂

As it happens, I’ve landed myself a right sweet little number. The company is still quite small and has been trading for only a few years so there is lots of room for growth (both for the company and, I hope, me too). Also (and the main reason I accepted the role), the people there are absolutely lovely. A right crazy bunch; but then it is in the media advertising business space so I guess that is to be expected. This is a new industry for me (in terms of the vertical market the business operates in) but it’s a pretty exiting one and the overall sense for me is that it’s probably a good place to be right now in terms of future potential and prospects.

As far as my role goes, I do have my work cut out for me. Whilst the Engineering team have done a sterling job to get the product to the place where it is, it’s a typical story of a company that is (or, rather, was) still very much start-up mode. Basically, it’s a case of a JFDI (Just F…ing Do It) approach to delivery schedule management with best practice in terms of engineering protocols and processes taking second place to the wants and needs of the commercial side of the business. Of course, this is quite understandable since this is what pays the bills but this is also an unsustainable way of operating a growing Engineering team; it’s a house of cards just waiting to collapse.

The term for this is “Technical Debt”. Basically, an engineering team, unless allowed to proactively keep on top of maintenance and development schedules, will fall into debt with their workload. Actually, I am slightly abusing the term as has a slightly more refined definition that than; however, the semantics apply here in the sense that if a team is overworked and understaffed (or just under-organised) it will build up a backlog of work that it struggles to get done. The backlog will just grow and grow (like debt), meanwhile, the team often ends up “borrowing from Peter to pay Paul” by making promises to deliver one item at the cost of failing to meet other deadlines. This trick only holds for so long before all your creditors call in their loans.

My job, initially, is to negotiate better terms for the debt incurred. This isn’t always easy since there is still a number of legacy issues that demand immediate attention; however, a lot of the time handling this comes down to expectation management. In other words, when people are used to getting engineering to drop everything for them because they have shouted loudly it can be quite a culture shock when they suddenly discover that shouting, no matter how loudly, no longer works. The trick is to try and demonstrate that a little bit of planning on both sides of the fence goes much further in getting things done.

Of course, you are asking for something (less shouting and more time) and so in return you must give something. You must give your word that your new processes and delivery schedules will meet the reset expectation and then, of course, you must deliver on your promise. Failure to do so will not only make you look utterly stupid it will also ensure your word no longer has any meaning. You only get one chance at this so… don’t blow it!

The trick to this is to ensure that your team are isolated from all of this as much as possible. Let them focus on the deliverables whilst you, the team lead, absorb all the shouting and fallout from the angry clients. A distracted team is a non-productive team; let them focus on getting the debt down whilst you handle the bailiffs. Fortunately, I am both thick skinned, quite large (both in personality and shear bulk) and not easily intimidated. These are all quite useful attributes when telling an angry sales manager that, “no we will not drop everything just for you because you wrote a cheque to a customer than my team cannot cash”.

In the end, I view this situation being like paying off a repayment mortgage. Initially, most of your payments go towards the interested but slowly but surely, month by month, you pay off less interest and more capital until, one day, you are debt free. This is the same with technical debt. Initially, you do a lot of hard work for very little payback; there will continue to be lots of angry conversations with sales managers and mountains of work that still needs doing. You still end up being quite a lot more reactive than you’d like but as long as you’re chipping away at the technical debt you eventually get to a point where you can be more and more proactive, leading to less and less reactive confrontation.

It’s fun but, boy oh boy, is it exhausting. Still, the challenge is to work hard now so you can work smart going forward; eventually getting to a point where we’ve proactively done everything that needed doing so you and your team can pop down the pub every Friday lunchtime for the rest of the day! Cheers!

Like this:

Related

Published by evilrix

An expert in cross-platform ANSI C/C++ development; evilrix specialises in high performance/low latency solutions and complex meta-template programming techniques, using Boost and the C++11 ANSI standard.
View all posts by evilrix