Technology Zoo in Projects: What It Is, Causes, and Solutions

What Is a Technology Zoo in a Project

Technology Zoo is a situation when a project or company uses an excessive number of heterogeneous tools solving the same task. For example, three different HTTP clients (Alamofire, OkHttp, Ktor), two state managers (Redux, MobX), and three databases (Realm, CoreData, SQLite).

The difference between a zoo and a deliberate choice of different tools for different tasks is the absence of a strategy. If team A chooses React Native, team B chooses Flutter, and team C chooses Kotlin Multiplatform without a common decision — that's a zoo. Diversity itself is not harmful; its uncontrolled nature is.

Each new stack in a project increases cognitive load for developers. To work effectively, one must remember the nuances of all technologies used. According to Google (2024), context switching between different stacks reduces developer productivity by 23% compared to working in a unified technological environment.

Causes of a Technology Zoo

Decentralized decisions are the main cause. Each team chooses technologies for its project without regard to the overall strategy. The backend team uses Kotlin, the ML team uses Python, the mobile team uses Flutter. Individually, the decisions are correct, but together they create a zoo.

Mergers & Acquisitions (M&A) — when a company acquires another, technology stacks merge. Two systems solve the same problems differently. Example: after acquiring a startup, a large company gets its Ruby on Rails stack, even though the internal standard is Java Spring. The question arises: rewrite or maintain two stacks in parallel.

Changing trendy technologies — each hype cycle adds a new stack. In 2015, everyone wrote in AngularJS, in 2017 — in React, in 2020 — in Svelte. Without discipline, a project accumulates layers from different eras. Legacy modules that work but are not supported add heterogeneity without the ability to quickly eliminate it.

Why a Zoo Is Dangerous for the Team and Business

Onboarding new developers turns into learning 5+ different technologies instead of one. Instead of a week to get into the project, a newcomer spends a month mastering all the tools used. Time-to-productivity grows proportionally to the number of stacks in the project.

Context switching — a developer working with 3+ stacks during the day spends up to 30% of time restoring context after each switch. According to University of California (2023), after each switch, it takes 23 minutes to return to the original productivity level. With 5 switches per day — almost 2 hours lost.

Security risks — each stack requires updates, vulnerability monitoring, and knowledge of best practices. A team cannot be an expert in all technologies simultaneously. Dependency fatigue — when the number of libraries used exceeds the team's ability to track and update them — is a direct threat to product security.

Infrastructure complexity — CI/CD needs to be configured for each stack. Different build systems (Gradle, CocoaPods, npm, pip), different environment requirements. The infrastructure team spends resources maintaining heterogeneous pipelines instead of improving them.

How to Diagnose the Problem in a Project

Stack inventory — compile a full list of technologies used: languages, frameworks, databases, CI/CD, monitoring systems. For each technology, note the number of projects/modules, support level, and the number of developers proficient in it at a professional level.

Technology Radar — a ThoughtWorks method dividing technologies into 4 quadrants: Adopt, Trial, Assess, Hold. Adopt — recommended stacks, Trial — experimental, Assess — under evaluation, Hold — not recommended for use. Example: Flutter in Adopt, React Native in Hold — teams understand what to choose.

Maintenance cost metric — estimate how many engineering hours are spent on maintaining each stack per month. If a stack consumes 10% of resources but is used in 2% of modules — it is a candidate for replacement. A stack heat map with axes "number of projects" vs "maintenance complexity" clearly shows problem areas.

Methods for Standardizing the Technology Stack

Architecture Decision Records (ADR) — documenting architectural decisions with justification for technology choices. Each ADR contains context, alternatives considered, and arguments for the choice. Michael Nygard (2022) popularized this approach, and today ADR is a standard for teams controlling technology diversity.

Technology Review Board — a committee of lead developers that approves new technologies in the project. Decisions are made based on criteria: compatibility with the existing stack, community support, cost of migration, talent availability. Spotify has been using a similar committee since 2018.

Gateway for new projects — a rule: any new service or module uses only the approved stack. Exceptions are possible through ADR with justification. Example: a new microservice can be written in Kotlin only if the team proves that Java is not suitable for this task. Barrier-free use of any technology is prohibited.

Gradual Reduction of Stack Diversity

Phase 1: Freeze — new projects on unsupported stacks are stopped. An end-of-life date is set for each stack in the Hold quadrant. New functionality is written only on approved stacks. Legacy modules continue working but are not extended.

Phase 2: Consolidation — one tool is chosen for each task. One HTTP client, one state manager, one database. Modules on alternative stacks are scheduled for migration by priority. Strangler Fig pattern is the main method for replacement without system downtime.

Phase 3: Migration — each sprint, the team allocates 20% of time to rewriting critical modules from outdated stacks to approved ones. Target architecture is documented and does not change without a committee decision. The process takes from 6 to 24 months depending on the scale of the zoo.

Example: HTTP Client Migration

// Before: 3 different HTTP clients in one project
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}