The most unpleasant debts are not about money. When we speak about a money debt, we always know how much we owe. Technical and management debts are much worse. In both cases, you never know how much you will have to pay.
Technical debt. It appears when something looks and works as planned but actually is based on unreliable and inflexible solutions. In this case, you cannot expand the system. We get technical debts when we try to create something in a hurry. In the long term, it is very expensive.
|How to avoid
|The code that works, but is stupid and messy.
|It is impossible to understand and support this code, so it is easier to develop a new one from scratch.
|Create smart and clear code, using the guidelines.
|A complete mess in project files. You cannot understand how and where they are connected.
|In the end, the mess will result in a situation when you have to stop working and spend a lot of time making things out. Or it will lead to a mistake and its consequences, which is much worse.
|Always keep your files in order.
|You have a task – to fix a typo in the layout. You do not have the layout file at hand, you have only a PDF-file with texts for printing. You fix the typo in this version.
|At best, the work with this version will be long and tedious and will result in imperfect design. At worst, the layout will be printed with a typo.
|Spend some time, find the layout file and fix the typo right there.
Management debt. It happens when the situation looks fine, you think that you have answers to all the questions and the expectations are synced. In reality, it is not fine at all.
|How to avoid
|When your team or clients have questions or doubts, you just say: “Oh, don’t worry, it will be fine”.
|It will be really bad.
|Pay attention to complex things, speak about what can go wrong, admit that something is not perfect.
|You get a task and promise to do it. You do not check if everything is clear, if you have enough data and if the links are valid.
When you start working, you have questions, and cannot get answers as the person who gave the task is not available.
You do not actually know the volume and you plan by guess.
You feel very ashamed when you say that the task will take three days and then request access to the files at the very last moment.
|Make sure you have all the files, check and understand everything beforehand.
|A client says they like the design, the texts and that everything is great. But you hear some uncertainty. Most likely it happens in the middle of a project or closer to its end.
|Sometimes a client feels uncomfortable about the fact that they changed their mind. It is our problem, not theirs. Their uncertainty won’t go away, it will only grow. At best, you will have to make it all over again, but later. At worst, the client accepts the project, but it never goes live.
|Be ready to accept any remarks at any moment and find a new solution.
|You do not understand something in a talk. For example, you do not know some term. You are afraid to say “I don’t get it”, and the longer you listen, the less you understand and the more afraid you are to admit that you do not get it.
|In the end, you will have to admit that for half an hour you have not had a clue what it is about, you’ve wasted time and you will need to start over.
|Say that you don’t get something as soon as it happens.
|You are afraid to say that something is wrong and instead you are trying to make things look smooth. When they ask “How many sections are ready?” you say: “Well, I am finishing one right now, and tomorrow I will make two more”.
|After some time the gap between the reality and its inflated estimate will grow, and you’ll face a problem.
You should give a straight answer: “At the moment none of the sections are ready”.
You should never hide problems, but take responsibility and ask for help.
If you want to work without debts, here are three rules:
The rule of a single way. We cannot have two ways for doing a task: one for situations when we have time and the other for the cases when we don’t. There is only one way: a good one, without temporary fixes and rush solutions. You should do the task as good as you can.
The rule of filtering problems. You can have incoming problems, but never outgoing ones. You can receive bad texts, unclear code, you can get a project with a mess or even a conflict inside. You do not let the problem go past you, you find a solution to it. If you need to stop everything to fix the problem, you do it, fix the issues and restart the work.
The rule of constant order. You cannot have the order on certain days only. You should keep it all the time, it should be a part of your work process. Order on certain days is actually a mess.