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
