An extended version, beyond the limit of 140 characters, of an interesting discussion
Today I posted this on my social accounts:
The first rule to reduce technical debt is: you don’t create technical debt.
But that was my intent (not just for the sake of igniting a flame). I wanted to see how my words would be understood and interpreted by people. Because everything here is about the words.
There are three keywords in that phrase. The first one is ‘reduce’. The second one is ‘technical debt’. And the last one, the most important for me, is ‘you’.
Let’s start with the first one, which was misunderstood (at least, looking at the comments).
This is the premise of all the argument: if you want to reduce the technical debt. There is an ‘if’ so it means that you want to, there is a commitment or an agreement for that. Whatever the reason is, this means it’s a problem, something you want to/have to work on.
Not only: it’s about the reduction, so there is already an existing amount of technical debt. So we are not talking about the ‘creation’ of technical debt (this is the suggested solution, but we’ll get to that in a moment) but about a possible solution to cut back the existing one.
If you have come to the conclusion that you need to reduce it, it means it has become a problem, a burden to minimize. That’s my hypothesis here.
(Le me be clear. It’s absolutely acceptable, I would say physiological and healthy, to have technical debt in a software project. I think the complete absence of debt would be a symptom of some kind of dysfunction.)
The second keyword is the one that heated the discussion. For two simple reasons.
First of all, because everyone has its own interpretation of what “technical debt” means. It has a very broad meaning since there is no definition of what ‘technical debt’ is. That’s absolutely subjective and depends on the context (read the comments to my posts, for that).
One of the most used counter-argument has been: “If you are a startup technical debt is a good thing. Otherwise, it means you’re not being pragmatic enough, you don’t ship fast (or ever), you’re too slow to the market.” Who doesn’t agree with that? As I pointed above, technical debt can be healthy or even looked for in order to have a working business.
But that was my little trick here: to use this generic word in this way.
Think of it: if you call something ‘technical debt’ this means you can recognize it, you have somehow an idea of what it is. And if you want to reduce it, also of why you want to do it, what are the problems that it’s bringing. So, stopping to add new technical debt on top of existing technical debt isn’t one of the simplest ways to reverse the trend? How can this idea be so contentious?
Well, there is another reason why I think it triggered a lot of reactions: because it appeals to our own experience, our bad memories of messy codebases, even our self-esteem (“What? I am not the one that creates technical debt! I am a good developer.”) and so we tend to interpret/filter/bias the phrase through these lenses.
And this leads to my next point.
The last keyword, the one that I consider the most important, was also the one that went unnoticed.
It’s been decided (you or your team has agreed) that the technical debt has become a problem, and needs to be reduced. Then why things don’t improve? Why?
Well, because of you.
Yes, you. Really, I mean you. You who are reading these words. It’s your responsibility, your duty to stop adding new technical debt.
If you want to decrease your technical debt, stop adding new technical debt in the first place. Apparently quite obvious, I know, but that’s the whole point of the discussion here. (Again, if that was the decision. That’s the premise, of course).
But everything starts with you. Not with your colleague(s). Not with your team. Not with the good principles and best practices saved in a wiki page or printed on a wall.
If your codebase is filled with technical debt (usually cut-corners and will-dos, but that’s not the point here) it’s because someone has “put it there”. It’s not that one day magically it appeared. Or that someone or something added it for some reasons, overnight, little by little. That technical debt it’s there because of you (ok, not only you, but that’s not the point I want to make). You have decided that there was not enough time to make something properly. Or that fixing that problem immediately it would have required too much hassle, so you have just opened a new ticket. Or that the code you wrote, at the end of the day, was working so why bother to find a better way to implement it.
We tend to think that the solutions to the problems rely on something that is exogenous, external to us. A tool, a process, a list of good intentions, a mutual agreement. Something that regards everyone, and so at the end no one. Especially, not ourselves. Not you.
Things don’t change if you don’t change.
(And just to be clear: that ‘you’ it’s not only you, it’s also me).
Now, try to re-read my sentence, and put the stress on the word ‘you’:
The first rule to reduce technical debt is: you don’t create technical debt.
How does it look like? How does it sound? Makes more sense now?
Can you understand what was my point now?
Addendum: my badge of honor for all this story is this:
I don’t know if his ‘like’ is because he agrees with me or because he just wanted to encourage me (“oh, poor kid”). In any case, it made my day. Thanks, Jacopo.
Also syndicated to Medium.
Alcune riflessioni sul tema big-data e giornalismoFebruary 9, 2017
- January 21, 2017
Being rich with all I have gained on the wayJanuary 3, 2017
My experiences being interviewed for a job. And someone else's views on the recruiting process.November 6, 2016
- November 4, 2016
Two hundreds years have passed, but still technical choices are discussed on the tip of personal tasteOctober 3, 2016
An inspiring evening about interactions, humans, agents, instability and hacks.September 29, 2016
A transcript of the Interaction Design London meetupJune 30, 2016
- June 24, 2016
A series of interviews on BEM methodologyMay 12, 2016
Writeup of a special event in LondonApril 26, 2016
An unexpected conference in NewcastleApril 21, 2016
Some good news from a very personal point of observationMarch 2, 2016
I've joined the company as Mobile Web Developer.January 25, 2016
After 16 months of hard work, it's time for me to take new roadsJanuary 18, 2016
Una riflessione in pausa pranzo, nata da una discussione fra amiciJanuary 6, 2016
- December 1, 2015
Don Norman and Bruce Tognazzini explain how and why they formalised the principles of good, understandable design in Apple’s Human Interface Guidelines (and much more)November 25, 2015
If you have eyes to see, it will tell you a lot about your team (and your company)October 1, 2015
How a small (in size) but great (in content and people) meetup becomes “epic”September 29, 2015
The building blocks of the web are small components, but you need a systemic view to win his inherent complexityJuly 27, 2015
(OK, kinda melodramatic as a title, but I do not get a better metaphor)July 15, 2015
(OK, un po’ melodrammatico come titolo; ma non mi viene un’altra metafora)July 8, 2015
An open letter to a special personJune 5, 2015
Are we building the web, or digging a hole around it?June 2, 2015
It should be easy to answer this question, right? Instead...April 30, 2015
A newsletter with hand picked interesting links, delivered in your inbox every day at lunch timeApril 15, 2015
Then, and only after that, it becomes (also) a creative effortFebruary 25, 2015
(or Design, as you like)January 20, 2015
More and more “fanboys” can no longer bear the inglorious decline of Apple’s softwareJanuary 10, 2015
Some notes, resources and links that helped me while preparing the talkDecember 3, 2014
I am so happy that I had the opportunity to take part to it, as a speaker and attendeeDecember 1, 2014
Some quick notes from the TechTalks@CassNovember 14, 2014
The hard truth about CEOs and their “ability” to sink a companyNovember 10, 2014