Technical debt will eat your feet
No matter what you believe, no matter what you do. If you befriended Technical Debt, you already know, what’s coming. Eventually.
Here and there, social networks offer some technical debt related brawls, jokes, memes and more or less relevant thoughts. My thoughts are the grumpy ones.
The boring part
The boring part of technical debt is it’s formal nature. Which is very well described in here Technical Debt. I won’t be re-inventing wheel talking about theory. I will write from the developer point of view.
Birth of the devil
The starters
“We are only about to start. We need just some prototype/demo/MVP. Let’s just hire some cheap guy who will do this for us. There is even the internet full of an infinite number of people who are capable of finishing it yesterday. We won’t waste time defining, we will just push, push, push, pivot, pivot, pivot, push”.
This is often the investor, who has good intentions, but is not very experienced in the field, has no idea about budgets, burning money in development. And they try the best they can do.
Haven’t experienced this from the beginning a lot, I mainly jump in, once such a product has a few years behind and plenty freelancers, contractors and interns behind. It started as a job offer on one of plenty freelancing markets, where people were offering incredible confidence, nicely crafted portfolios nobody ever explored, because who would lie in our world, right? They know something, but you can even sometimes google the snippets they used, including 4 years outdated libraries and/or tools. Because that outdated manual did not work with more recent versions.
The moment things start breaking apart, they disappear. If you hire more people of this kind at the same time, they will compete with each other, not forming a working team. Because that other guy could be better and take everything, so let’s get rather rid of him.
If such “starter product” has sane investor, they will start over. Some will just continue hiring new cheap people and they do it 2-3-N more times until they are forced to start over. Or just throw it away, because the new shiny idea just rings behind the door.
The problem of the product is not only the code quality, but the months spent discussing it with new people, explaining, evaluating, testing, fixing . It immediately causes close to zero patching/updating procedures to exist and being executed.
The ad-hoc-ers
“We just need this. Fast forward days/weeks. And add this, remove that, add this more, this one is similar to the first requirement, should take you only so much time it took me to ask you”.
I hate these. They have something done, they experienced some success, they feel like they know best. They want a button, right, it only takes less than a second to click that button, why should it take hours to make it work?
It is not worth fighting in this fight of balls. So sooner or later, they will end up using the same cheap “do it all” people mentioned earlier.
The philantrops
“We welcome people who want to learn, we will let them explore and grow”.
If they want to do filantrophy, they can still open intern positions and burn money there. With the exception, they won’t let interns do the important work and at the end of the internship, they will know who is worth it and who is not. But for unknown reasons, some people do this for permanent positions too. Hiring over-confident people who don’t have experience, but they claim how they want to learn. They are honest, mostly. They really do. But that says nothing about their potential. And also says nothing about their desires. Some of the people from such hiring will be just useless people, some other will sit there and will switch job the moment somebody will offer them 5 more bucks, because they gained some paper-proof experience. The worst case, they won’t be able to find another job. You will be the only option.
And the investor? They will have an unofficial stack overflow snippet mirror in their code base if they do this regularly.
The hipster money-burners
“We have table football, table tennis, more relaxing room than office room, gazillion of tea and coffee types, our own chef, relax when you don’t feel to work”.
Here, I may be biased, because I personally like to distinguish work-time and the rest of the time. I experienced this many years ago, having all these goodies in the offices. Sometimes felt like it is a kindergarten. And the task board and workflow seconded it. A kindergarden development. With frustrated clients, management and stuck projects.
The gamblers
“Let’s not waste time evaluating candidates, we will figure out in the process”.
This is actually similar to “The philantrophs”, with the difference they seek experienced people. They like to get fooled by nice speeches about the joy, attitue, hard working and sarcrificing everything. But people with such an attitude don’t have to present it, because word of mouth does it for them. So whoever talks to you like this and they are not freshmen, they are fooling you. In a healthy conversation, both sides should know what the investors seek and what the candidates offer.
In such environments, these imposters have gained some general trust since the beginning and it takes some time until they are terminated. The morale of the team is already destroyed, code worth considering whole replacement. And not so rarely, the same story just repeats.
The octopuses
“We have multiple prospects from different fields, let’s prototype for everyone, something will be a success”.
These are similar to money burners. No focus. None. Ideas, desires, talking to prospects, burning money to develop different products, ways. One will be a success, right? Because we deserve success. It won’t happen. Most likely. The world is not fair, doesn’t matter what they deserve. They will either burn all money sooner than something is finished, or they will burn out people with constant context switching, doing prototypes to be demoed instead of making actual progress.
The righters
“Your opinion is interesting, but we hired you to do what we tell you, your experience helped you make it through, here it does not matter anymore, because we know it better.” In such environment, everyone is just a laborer. Worse, if responsible for the crappy output they were forced to build. What goes hand in hand. Such toxicity can’t be eased. Just run. Don’t stop.
The devil will eat your feet. Or murder you
So, what is it like to be the investor (company owner, manager). If they are the good ones, they want to build a steady, growing, long-lasting business. And for some reason, they expect all people they work with to have the same attitude. Most employees won’t be like that. Some won’t care at all, some just won’t be the right people for the job, some will sit there for 8 hours and goal met. Some will just wait to gain some experience to get a dream job.
That’s the reason, why there should be no excuses and no marketing-like managerial BS. Investors won’t push more from people, I don’t think it is right as well, but their duty is to push the right amount and make sure all the amounts will fit together. If there are mis-fitting parts, either fixing it or letting go. That guy. He will be maybe pissed. But he will figure his way forward.
Fight the devil
It is important to have a good working environment, but there should be always accent on the working parts. Trust is important, but as important as due diligence. Having rules is not about hierarchy, it is about the system you want to work for you. Not hesitating when terminating contracts with people who don’t fit is usually a sad or even stressing thing to do. But it is less sad and less stressing than convincing good people to stay when they are on the move. Or when your product falls apart and nobody owns a magic wand.
You know how hard it is to upgrade some software from version A.A.A to A.B.A, right? So, why do you think it will help waiting till the only working upgrade available is A.A.A to A.G.A? Do you know it is a chain reaction of upgrading many related libraries, rewriting some features, figuring out which features were discontinued, which have now different behavior…
You don’t have to be TDD. It is not so practical in many applications. But you know what happens when you change that non-important function somebody created 3 years ago and all people only guess how it works? Would just simple coverage help it? So you have not covered it before, you don’t have time now, you will wait if some obvious issue appears in production?
Nah, this ad-hoc configuration change you did and forgot about won’t hurt you in the future.
Clueless people doing something and then hiding and pretending they have no idea what happened. That is very helpful.
I don’t think it requires much to minimize the technical debt. It will grow, no doubt. Many times during the life of a product, there will be decisions made which are important and will just push you some rests. But these are enough. Don’t add some which are easy to prevent.