Bicycle in Programming: What It Is, Causes and How to Avoid

What Is a Bicycle in Programming

Bicycle is a term from the developer community that refers to creating your own implementation of functionality already available as a ready-made library, framework, or service. In English-speaking environments, the expression “reinventing the wheel” is used. In the Russian-speaking community, variants like “velosiped,” “custom implementation,” or “own bicycle” are also used.

The origin of the metaphor is related to the fact that the wheel is one of humanity’s oldest inventions. Trying to reinvent it in the 21st century is pointless. In programming, the analogy is even more accurate: ready-made libraries are “wheels” that have been optimized by thousands of engineers over years. Creating your own wheel of inferior quality is a waste of resources.

RedMonk in an analytical report (2023) calculated that the average commercial application uses about 500 external dependencies. If developers had to write each of them independently, the project cost would increase tenfold and time-to-market would stretch for years. The ecosystem of package managers (npm, Maven, PyPI, NuGet) exists precisely to avoid reinventing the wheel.

Signs of a Bicycle

Code that is a bicycle can be recognized by several signs: it solves a standard problem in a non-standard way, has no tests or documentation, and does not handle edge cases that have long been addressed in ready-made libraries. Often such code is written expecting “unique requirements” of the project, when in reality these requirements are no different from typical ones.

Difference Between a Bicycle and a Custom Solution

A custom solution is justified when a ready-made library does not fit due to architectural or licensing constraints. A bicycle is created without objective reasons — out of a desire to “play around,” distrust of others’ code, or ignorance of existing tools. The difference is fundamental: a custom solution is a conscious choice, a bicycle is a mistake.

Why Developers Reinvent the Wheel

The first and most common reason — ignorance of existing solutions. A junior developer may not know that the standard library has a built-in function for parsing JSON. Instead, they will write a parser manually. This problem is especially relevant for beginners who are just entering the language ecosystem.

The second reason is the illusion of control. Experienced developers are sometimes convinced that they “can write it better” than the authors of a popular library. Statistics say the opposite: the probability of an error in a library used by millions of projects is significantly lower than in freshly written code. According to Synopsys (2024), open-source code contains on average 0.1 errors per thousand lines, while corporate code has 1–2.

The third reason is the lack of a culture of reuse. In companies where it is not common to research existing solutions before starting work, each developer creates “their own bicycle.” This leads to code fragmentation: one project may have three different HTTP client implementations written by different employees.

Psychological Aspects

The IKEA effect is a psychological phenomenon where a person values what they created themselves higher than objectively better ready-made things. In programming, this manifests as pride in “your own bicycle” and unwillingness to replace it with a ready-made library even when the latter has obvious advantages.

Consequences of Creating Bicycles in a Project

Economic consequences are the most obvious. According to a Stripe estimate (2022), developers spend up to 35% of their working time creating code that already exists as ready-made solutions. For a team of 10 people, this translates to about $200,000 per year spent on reinventing the wheel.

Technical consequences include codebase growth, reduced test coverage (custom code is usually tested worse), and an increase in bugs and vulnerabilities. Moreover, every custom component is another point of failure that needs to be monitored and maintained.

Google in its study “Why Google Stores Billions of Lines of Code” (2023) noted that even in the largest technology company there is a strict decision-making process for adding a new dependency or writing a custom implementation. Most internal teams first look for a ready-made solution in the single code repository.

Impact on the Team

Bicycles create information asymmetry: when one developer leaves, their custom component remains without documentation and support. New team members have to understand non-standard code, spending time that could be used for productive work.

Examples of Common Bicycles in Code

The most common example is manual JSON or XML parsing, even though almost all modern languages have built-in tools. Developers write recursive functions for traversing object trees, not knowing that JSON.parse() solves the problem in one line.

A second example is a custom HTTP client implementation. Standard libraries (fetch, axios, OkHttp, URLSession) support caching, reconnection, timeouts, and security. A custom client usually fails to account for at least one of these requirements, leading to bugs in production.

A third example is a custom logging system instead of using SLF4J, Winston, or Log4j. A developer spends weeks writing what ready-made libraries do out of the box with support for rotation, log levels, async writing, and monitoring system integration.

# bicycle — manual CSV parsing
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# using standard library instead
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Anti-Pattern: Custom ORM

Writing your own ORM (Object-Relational Mapping) is perhaps the most expensive bicycle. Ready-made ORMs like Hibernate, Entity Framework, or SQLAlchemy have been developed for years, supporting caching, lazy loading, migrations, and dozens of DBMS. A custom ORM is usually limited to one database and contains critical errors in connection management.

When a Bicycle Is Justified

Learning is the only situation where a bicycle is not just justified but also useful. Writing your own parser, HTTP server, or ORM for educational purposes helps understand how these tools work under the hood. It is important not to confuse a learning project with production code: what is good for a pet project is unacceptable in commercial development.

Unique requirements may indeed require a custom implementation. If no library supports a specific protocol, data format, or hardware platform, creating a custom solution is justified. But before that, you need to make sure the task is truly unique and not just poorly researched.

Licensing restrictions are another legitimate reason. Some open-source licenses (GPL, AGPL) may be incompatible with a company’s business model. In such cases, developing your own implementation under a more permissive license is justified.

The Rule of Three Attempts

There is a practical rule: before writing your own implementation, try to find and test three different ready-made solutions. If none fit, create your own, but document why the existing options were rejected. This protects against unconsciously reinventing the wheel.

How to Avoid Creating Bicycles

The first step is forming a habit of searching for ready-made solutions before starting any standard task. Use package manager searches, GitHub, Stack Overflow. Time spent on research pays off many times over by avoiding writing custom code.

The second step is implementing code review focused on identifying bicycles. During review, ask the question: “Why aren’t we using a ready-made library for this task?” If the answer contains no objective reasons, it’s a bicycle. In large companies (Google, Meta), code review includes a mandatory check for reinventing the wheel.

The third step is creating an internal knowledge registry. Document which libraries and tools are used in the project and what tasks they solve. New developers should have access to this information so they don’t create bicycles out of ignorance. Maintain a list of Architecture Decision Records (ADR) with reasoning for each choice.

• Research the package manager before starting a new task
• Check the language’s standard library — it covers 80% of typical tasks
• Use code review to identify bicycles
• Document decisions about library choices
• Update your knowledge of the ecosystem at conferences and in blogs

Not Invented Here Syndrome

NIH syndrome (Not Invented Here) is an organizational bias against using external solutions. Companies with NIH syndrome prefer to develop everything in-house, rejecting open-source libraries even when they surpass their own development. This syndrome is the corporate version of a bicycle.

A classic example is Netscape in the late 1990s, when the company spent years rewriting the browser from scratch instead of evolving the existing codebase. The result — loss of market share and acquisition by AOL. In contrast, Android is built on the Linux kernel and uses thousands of open-source components — this allowed bringing the product to market in record time.

A study by Harvard Business Review (2023) showed that companies with low levels of NIH syndrome bring products to market 40% faster and spend 30% less on development. A culture of code reuse is a competitive advantage in modern development.

// bicycle — custom sorting implementation
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// built-in sort — standard solution
arr.sort((a, b) => a - b);