Why Large Companies Frequently Rebuild Their Own Tools and How to Manage It Effectively

Why do big companies love to reinvent the wheel? First, reinventing the wheel happens everywhere; here are a few screenshots.

It's not only big firms; medium‑sized companies also reinvent wheels. As the saying goes, people are diverse. The reasons for reinventing wheels can be summarized into the following categories.

1. Existing wheels are not usable.

Many open‑source products provide wheels, but they often meet only 80%‑90% of the needs; many still build their own to cover the remaining 10%.

2. To showcase technical strength and get promotion.

What you build yourself is always the best.

3. It's not that you want to build; your requirement priority is too low.

Some middle‑platform teams categorize services into first, second, N‑th rings; when your request is outside the third ring, you can't rely on them and have to build it yourself.

4. By building wheels, improve technical competence.

Nowadays, discussing business systems can be shallow; talking about JVM tuning, RPC/message/distributed scheduling provides a “common language” that pleases both interviewees and interviewers.

Are there benefits to reinventing wheels?

According to senior G, there are indeed benefits.

Business is king; to meet business needs, you must find any solution. If no wheel is available, you can modify one. When Dubbo stopped being maintained, we tinkered with Dubbox. If the tool/platform team doesn't accept your request, you have to build it yourself.

How to optimize a company's many “wheels”? It may look innovative but could be “reinventing the wheel behind closed doors”! Senior G suggests several directions.

1. At the company level, define the relationship between organization and business services. Top‑down problems should not be left to lower‑level teams to scramble. For example, should the social and e‑commerce divisions share RPC frameworks, messaging, logging, and task scheduling? Even if not, the group evaluates revenue, so focusing on core wheels reduces business service manpower. This tests leadership’s management ability, cost, and responsibility allocation.

2. If a middle‑platform team provides core middleware, its performance should be evaluated accordingly. Both social and e‑commerce divisions' needs must be met without favoritism; aligned KPIs ensure accountability.

3. Within divisions, unify promotion criteria. If small department A and B both deliver business results, the business pays; if they duplicate effort, a visibility window is needed for assessment, encouraging or discouraging duplication. In some firms, unclear platform relationships block promotion.

4. Positively encourage collaboration. At Microsoft, employee compensation is linked to impact, which emphasizes cooperation; during reviews, one lists collaborative teams and outcomes, and higher collaborative impact leads to higher performance scores, reducing internal competition.

It depends on the insight of technical leaders. As the saying goes, what the leaders like, the followers will emulate. NetEase’s Wang Yuan lamented that if DDB had been open‑sourced earlier, ShardingSphere might not exist. Open‑source tools receive continuous improvements, whereas self‑built ones may become unmaintained after two years. Leaders must decide what to build on giants’ shoulders, what to keep original, and what to share for greater longevity.

Some wheels that are popular today may just be a speck in the long river of history.

If you mock others' code today, future generations may lament it without learning, leading to repeated lament.

Reinventing wheels must be done cautiously; let’s strive together.