What is technical debt

Technical debt refers to a programmer’s reluctance to change legacy code for fear of breaking existing systems (or inability to design for quick business implementation). According to research on the subject, 59 percent of Business leaders in Norway say technical debt is the main obstacle to their innovation. When you have a lot of technical debt, it feels like you’re trying to steer a boat with the anchor still stuck to the bottom of the sea.

The origins of technical debt and the mechanisms that produce it are actually quite easy to understand. It happens because of “little quick requirements implementations” in your system (= voiceover = business: Add another if statement to an already complex function until your software becomes so complex that no one dares change it for fear of breaking other parts of the system unintentionally. Software developers refer to such systems as “shit mountains” or “spaghetti mountains of shit.” Paradoxically, we’ve known for decades how to avoid technical debt — yet “no one” follows this recipe because, and I quote; “They don’t have time.” So hackers are applied to existing systems until they become so complex that all future innovations are stifled and everyone suffers. Accumulating technical debt, and the process by which it is generated, is the equivalent of building a house on dirt.

For the domestic sense is more caused by the environment; 996, volume, chasing wind, earn money, most companies pursue is flexible, rapid iteration, the pursuit of the present, the project can survive next year is unknown, simple demand code also consider the year after? Hire someone to rebuild after you make moneyCopy the code

Why is it so important?

The company may wish to change its business processes at some point in the future. For example, your Marketing Department may find that changing some in-table logic attracts a lot of new customers, and the Marketing Department may want to change the order of some fields. If your system is a big 💩 mountain, this simple change is usually impossible. This is because your business processes are implemented based on the current software architecture, and if you cannot change your software architecture, you cannot change your business processes. This results in your business not telling your software department what they should do, but the software department usually telling your business that what they want to do is impossible. In fact, “it’s impossible,” I added, and you probably should, too.

“Wag the dog” comes to mind… :

What’s the solution?

Encapsulation is the key to avoiding technical debt. Encapsulation is “the art of hiding complexity”. For example, when I start my car, the process may involve 500 moving parts. But I didn’t have to think about those parts — I just had to remember to turn the keys in the right direction and the car would start itself after a while. If we can build our software like we build cars, we can avoid technical debt. Of course, if you ask most developers, they will claim that they do apply encapsulation — no matter how complex and confusing their systems are. So someone here is clearly not telling the truth……

I’m not blaming your developers. Most developers are nice guys and girls trying their best to please their managers — and technical debt is often accumulated as a result of “please make a change here again” without thinking about the long-term consequences. However, there is something fundamentally wrong with the way we build software…

Let me repeat that in case you don’t understand…

There’s something fundamentally wrong with the way we build software!

Know the… ?

If you ask the average developer to create a sign-up form for your Marketing Department to attract customers, he or she will be happy to start writing code and wait for the familiar pat on the back to tell the developer; “Well done!

Instead, developers should ask themselves; Has anyone else solved this problem before me? At this point, developers are likely to find that a microservices module has solved the problem, putting years of cognitive energy into the problem and producing a super-flexible registry that developers can bend to the wishes of the Marketing Department in the future. However, software developers have no incentive to do this because it is “less fun work” — from the individual developer’s point of view, the more times he or she actually codes, the more he or she learns. The more developers learn, the more valuable future developers become. At some point, you could argue that creative development approaches have the potential to sabotage their boss’s project with personal motives!

Again, it’s not the developer’s fault, it’s systemic. The system is rigged, and it is rigged in such a way that the messier the code delivered by individual developers, the more successful it is from the individual’s point of view. (Because no one but the original developers could understand it! Ha ha ~)

The truth is, we need to stop rewarding developers for how much they produce and start rewarding them for everything they don’t produce! Just because every time a software developer produces something, he or she accumulates technical debt on behalf of his employer, innovation becomes virtually impossible in the long run.

Instead of rewarding developers for clever things they create, we need to start rewarding developers for everything they don’t create — instead finding a beautifully designed component that works right out of the box and developers can run without applying a line of code; (Avoid reinventing the wheel)

Of course, it’s very difficult to run a software development department this way, because it feels like you’re paying developers to “do nothing.” But in reality, finding a nicely architeted pre-existing microservice can be orders of magnitude harder than implementing a big, poorly written 💩 mountain from scratch. I’ve said this several times before, but a good thing can’t be repeated, and its target audience is the developer who has the “Not Invented Here syndrome”…

Your job is not to build software, it is to think!

In short, because every line of code you add to your Git repository becomes an extra grain of dust that settles on your project, a mountain…

Source: servergardens.com/blog/the-or…