Tuesday, 20 May 2014

How Technical Debt Threatens Your Brain Capital


This article was originally published in Scrum Alliance web site. Unfortunately in there the pictures and text formatting do not look as cool :-)

Technical debt succinctly and metaphorically sums up the obligation we incur when we cut corners during software development. Most articles focus on the direct association between "debt" and its financial implications; after all, money is the language the big fishes in the pond understand. If it doesn't threaten the pocket, it is not (yet) a source of concern.

I fully acknowledge that not all debt is bad, as  John Piekos  explains on his post, "there are often valid reasons for accumulating technical debt.  Perhaps the underlying architecture has some scalability constraints, but getting the product to market, in other words, harvesting “business value” ($, customers), is more important to the business.  The key is for the Product Owner and Team to explicitly know that this debt was incurred, and accept that you may have to pay in the future be willing to accept that obligation.”

As regards the “bad” debt, justifying its fix can be hard because it typically does not result in anything the customers or users will see. Such debt cannot be measure effectively therefore you can't really see the true effect of addressing it. The payment terms on this debt can be onerous though.  Usually the cost is time or productivity, sometimes both.  This article touches on another often forgotten point: how increasing in technical debt threats your business knowledge capital.

Some time ago, when trying to understand a piece of voodoo code (nobody knows what it does, how it does, or how it could even possibly working) I was amazed to hear my co-worker saying that "yeah, I know this is bad… John has a way of delivering stuff very quick, but he's not really good with OO”. My heart sank. Quick and dirty delivery is like sweeping trash under the mat. The guests always find the house clean but someday the owner figures out that something is not nice.. It SMELLS - Real cleaning has to take place but by then the dirty is plastered all over the floor and it will take twice as much to get the job done. That day at work my task was to try to break that cycle, through refactoring I would exorcise that evil dark code and bring enlightenment so that not only John could deliver quick, but anyone who happens to be in charge of working with that functionality. Take that Father Karras!

Code exorcism aims to bring enlightenment into the darkness of the legacy code

Technical Debt will slow you down and eventually stop you

Code is not bread baking. Good code takes time to prepare. Period. Having longer work hours won't add quality to the code. Adding more workers to the team won't build it quicker - quite the opposite actually. Code has to be concise, decoupled, scalable and easy to understand - you spend way more time reading code then writing code so it has to be easy to read and digest. Every time you leave "bad code" behind, with the promise of fixing and re-doing it in the future, you increase the debt. In the long run (specially in places where hundreds of developers commit every day) the impact of such debt is that features will take more and more time to be developed since coders will take more and more time to understand how to do it and to figure it out the possible effects that such changes will create way down the line.

One of the important implications of technical debt is that it must be serviced, i.e., once you incur a debt there will be interest charges. If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., "servicing the debt") that there is little time left over to add new capabilities to the system. It's like a pick-a-stick game where a small change can cause the whole structure to collapse without you even being aware of it.

The snowball effect of accumulating debt

Developers fear changing the guts of the code - why bother to change a hairy huge enterprise size class if it’s working, right? The more you fear, the more you work around and through this cyclic process you increase your debt by adding layers on top of layers until you start asking yourself how such code could possibly even be working.


Avoiding debt increases the gap within the team

The Product Owner is part of the team. He’s got the mission of maximising the ROI by defining what the team will be delivering within the next Sprints. A healthy tension between the PO and the rest of the Scrum team is beneficial to generate the right amount of stress that drives the team forward in pushing to deliver more and better. It is like if the PO was the tough father pushing the kids to improve their grades, while the Scrum Master is the lovely mother who indeed want their kids to go better at school but also understands that they need some space to grow and mature and figure things out on their own so that they can improve not only in school but in life as a general.


By having a PO who constantly refuses to address technical debt issues you run the risk of having the development team mistrusting his decisions. It starts silently, with weird looks and faces when he/she leaves the room, to more behaviours like starting to question his understanding of the system, his prioritisation skills and even his appreciation of the dev team work since their needs are never taken into consideration.

This tension increases the natural gap that exists between someone who works close to the business and the ones who are in trench lines of development. The last thing you want is a sense of “us” versus “them” within your own team. When this happens a interesting and sad thing might also spring, developers will start inflating and hijacking stories so that they can inbuilt refactoring work alongside their tasks. Because they are done in the dark and not properly flagged, these refactors tend to lack enough discussion and formalisation and people within your team or on different teams working on the same product might start to feel left aside in terms of having the chance to suggest or discuss alternatives or other possible ways to go about certain architectural decisions and this only adds up to their stress levels.


Technical Debt is a morale killer

This is when things start to get interesting… 

morale
noun
    the confidence, enthusiasm, and discipline of a person or group at a particular time.

Keeping employee morale high is one of the best things you can do to instil loyalty and maintain a productive workplace. An artist satisfaction lies in being sure he performed according to his high standards. A musician would not be please by a poor performance, nor an artist with poor painting, so why would this be different for other kinds of creative workers such as developers? Would they be please by being “forced” to deliver poor quality code? Would you be happy feeling you are staling at your job?

Excellence is a matter of choice but at work, this choice is only real when you provide the right tools and environment for the ones who chose to excel. If the team spends most of your time firefighting they can’t learn. If you avoid dealing with your debt in a smart way you cannot avoid its growth or figure out cool ways to deal with it. 


I remember a First Aid course I’ve done a few years ago. The instructor asked me what would I do when arriving at an accident scene - there would be blood, people crying, screaming, people passed out, you get it. Who would you threat first? “The one who shouts louder I said.” He smiled. - “Wrong. You threat the ones that are not complaining. If they are crying they are alive. The ones who are not saying a word, these are probably the ones who are more seriously injured…”. The same applies to our work environment: you wake up everyday dreading your job, anticipating the headaches that are waiting for you the moment you arrive to your desk. The accumulating effects of this over weeks and months destroy the team’s spark and their willingness to change and complain about it. The moment they gave up moaning is the moment they've stop caring. Passion is lost. By this point it might be already to late to fix things.

Developers need to be praised. They need to feel that they are free and expected to excel in their roles, that they are adding value and making a difference. Developers are not code monkeys.


Fact - Technical Debt leaves you empty of good brains


Paul’s company sells furniture online. He’s got a real business to back it - big office with a few dozens employees, a large warehouse to keep all the goods and a small development team to take care of the website. He sees his business as “an online sale company” therefore the best he can do is invest in advertising to increase his presence on the web.

The dev team started by taking over an old website and building a nice interface on top of it but now it is getting harder and harder to add new functionalities or even change the code. They see the business as “a tech company who sells online”. The best Paul can do - on their opinion - is update the website so they can react quicker.

Paul’s main competitor recently started offering mobile phone access so that clients can easily shop. Paul’s team think they will need at least 3 months to reach this stage and they are getting behind… Does this sound familiar? In the new era of tech & web based companies, where clients come and go at light speed, and people like and dislike sites and technologies as quick, the only survivors are the ones who quickly innovate and adapt

To innovate you need good brains. You need great developers. These guys are not only motivated by a huge pile of cash. Good developers will make good money anywhere. Seriously. They are not attracted by money. This is implicit in being good on what you do, you are paid good. What they are looking for is nice atmosphere, good tools, good team, and great vibe. I have met developers who would code for food if they were offered the right challenge. 

If your company is famous for bad legacy code and lack of support to tackle it, you won't be able to keep the good guys. If you are not willing to improve your code up to modern standards you probably don’t even need these guys at all. Accept reality. Save company cash and get a few junior devs that will quit in a couple years but can get the job done one way or another. You do not need the best brains to do average work.

It takes months for a developer to get up to speed with the guts of your code, even more when it’s about bad and non-documented code. When someone leaves your team you are not only loosing an employee (to your competitors in most cases) but a whole lot of knowledge and information leaves your business with them. 

Demotivated people tend to react in unpredictable ways. They will speak badly about your business and its environment - in and outside the work place. They will quit without warning. People leaving affects team morale and even the way future potential employees see your business. Gossips about your work environment spreads quick around the dev community and once your business has established itself as a bad place to work it is very hard to get rid of this and attract bright minds.


Conclusion

I hope this might give you new insights and lateral ideas to stress higher up in the chain why it is important to have a reality check on how your business address or consciously prepare for acquiring new technical debt in the long road of the SDLC.

I believe the main point on addressing debt is not missing the chance of making good out of something bad. Yes, technical debt can be a pain but depending on how your company chooses to approach it can be a great opportunity to leverage the development team skills. Refactoring is a great opportunity to apply proper design concepts and bring less skilled developers up to speed with modern concepts and other best practices of software development.

Always keen to hear you thoughts complains or just stir the pot.

That’s all for now folks.


References

2 comments:

  1. Nice article, having worked as a developer before moving on to a product role I can definitely see both sides of the story but I like what you said about having a good level of "stress" in the team to keep things going and somewhat related, making sure people have something to complain about, which in your eyes equates to passion for the job. I do wonder if culture has to be a factor in this since UK citizens are less likely to complain openly about this as other, "warm blooded" nations ;)

    Good read!

    ReplyDelete
    Replies
    1. Thanks for that. I guess you could definitely say that culture is indeed a factor. As a Brazilian working in UK for the past 6 years I can honestly say people complain way more in here than back home but it tends to be more in the shade. I try to use this as an opportunity, it is not about being confrontational but trying to asks the “right” (maybe wrong) questions people try to avoid, in the “wrong” (maybe right) opportunities :-)

      Delete