Table of contents
1. Technical debt notes
1.1. What is technical debt?
In 1992, Ward Cunningham first proposed the concept of "technical debt" in the Agile Manifesto, which mainly refers to the debt accumulated by making wrong or suboptimal technical decisions intentionally or unintentionally. Subsequently, Martin Fowler, the author of "Refactoring", created a "four quadrants of technical debt" based on Cunningham's metaphor, including:
- Reckless/intentional: “We don’t have time to design”;
- Cautious/Intentional: “We have to deliver now and deal with the consequences of pursuing speed later”;
- Reckless/unintentional: "What is layering? ";
- Cautious/Unintentional: “We now know what to do”.
1.2. Discussion
Some time ago, the topic of technical debt on Reddit once again aroused widespread discussion among programmers. User spo81rtyOP said, “ The actual lifespan of most software is only 5 to 10 years. Even if the software survives, the fact that it is written entirely from an outdated technology stack will narrow its path. This is the life of a software engineer. True destiny. "
At the same time, in the past 20 years or so, many programming languages have also "fallen out of favor", such as Perl, Delphi, Fortran, FoxPro, and ColdFusion. Maybe these ancient programming languages still exist in some applications, but in most cases, companies that still use these programming languages have to modernize and retire the old applications. If you build a program in these outdated programming languages, you may end up rewriting it because it's hard to find programmers who use these languages anymore.
In the early 2000s, people thought Adobe ColdFusion was the hottest product, but what about today? Ruby on Rails may also go the way of Adobe ColdFusion, which has fallen out of favor and is having a hard time finding developers to use it . What was once unique to Ruby on Rails is now available in other languages.
Programming languages come and go, and developers don't want to learn skills they don't need on the job , Watson said . At the same time, developers move from job to job quickly, always hoping to have some hot new thing on their resume.
Watson predicts that WebAssembly will eventually surpass today's front-end development, and a whole new world will continue to evolve.
User chesterriley imagined an extreme possibility: Maybe one day in the future, people will continue to use code written 100 years ago. The big winner may be something like a Unix utility or TCP/IP code , or some compiler, runtime engine, or interpreter . There is also code from operating systems such as Linux or Windows . People may suddenly discover that the bug they fixed was actually from more than 100 years ago.
Of course, there are some codes that aren't really affected by today's hype. Interestingly, most of this type of code is concentrated on the server side . Although there are always powerful forces "subverting" the way services such as microservices and Lambda functions are built, if these implementation details are ignored, there will definitely still be db+ services running in the server's memory space, and there will still be idle cycles that are not utilized. .
“ I hope to see new projects born today keep the importance of long-term maintainability in mind, and even consider it as a basic design premise. After all, there are really not many people who have the ability to maintain old software projects. Even though the earth’s population is still has increased, but the number of developers with sufficient skills to maintain these ancient software has never been able to keep up. ”
1.3. What do domestic technology practitioners think?
Percent CTO Liu Yijing believes that the focus of judging technical debt is "what should be done". It is a process that varies from organization to organization, from project to project, and from person to person, such as the following aspects:
- What the organization requires but fails to do: systems, processes, norms, shared learning, etc.;
- Things that are required by business and technology but have not been done: functions, performance, security, high availability, expansion, monitoring, auxiliary tools, etc.
If classified according to software engineering links, technical debt can be divided into: requirements analysis, solution design, architecture design (logical architecture, functional architecture, data architecture, deployment architecture, operation architecture, etc.), coding, testing, release, etc. If divided according to the type of output, it can be divided into:
- Document category: management process documents, requirements analysis documents, design documents, test case documents, etc.;
- Code category: code, scripts, specifications, etc.;
- Software package category: product software package, dependent software, dependent resources, etc.;
- Environment category: development environment, test environment, pre-launch environment, production environment, etc.
As for how to decide whether to rewrite or continue to maintain, you need to judge whether the "benefit from continued maintenance" or the "benefit from rewriting" is greater to decide whether to continue to maintain or rewrite. The benefits from the following aspects can be comprehensively considered:
- Open source: Increase existing business income and support the development of new businesses;
- Savings: Save maintenance personnel and operating expenses;
- Organization: personnel structure adjustment and organizational capability development.
Debt is unavoidable. Always judge the "value of holding debt" and deal with it as soon as possible when the value is very low.
Tencent R&D Director Wang Hui said that if resources such as manpower, material resources, and construction time are abundant, anything that can be optimized can be achieved to the extreme. But usually, resources are not abundant, or they are stretched thin, so it depends on the actual business situation. Tencent's consistent approach is to "resist first and then optimize". Whether the project has really reached the point where optimization is necessary, and whether it has really reached the point where it may go down at any time if it is not optimized. If it resists first, it will wait until the business takes over the market. , after users have gained traction, and after the project progress slows down, some optimizations can be carried out again. At this time, high availability, high performance, high concurrency, etc. can be required.
"If the project resources allow, some slightly excessive optimization and refactoring are acceptable, and it is good to maintain the team's technical enthusiasm. But if the resources do not allow, you have to count the money spent and judge the reasonableness of the technical debt. nature, how to repay debt better, whether it is really necessary to repay it, whether it really affects business development, it needs to be looked at together with business priorities. If the business misses a time window, it may be missed forever. Some technical debt can be repaid later. ." Wang Hui concluded.