Ant Design Dora Metrics: Speedy, Sleek, and Almost There—But Can They Crack the Cycle Time Code?
11 min read
Ever wished building web apps was as easy as assembling IKEA furniture?
That’s exactly what Ant Design (AntD) feels like! Instead of building everything from scratch, you get a bunch of pre-made components—like buttons, tables, and forms—that you can snap together to create sleek, professional-looking apps in no time.
And, it’s impossible to get past this repo when you are doing a 100 days 100 Dora Metrics Case Studies initiative. Moreover, when you have Middleware OSS by your side, you get that itch to get a peek into repositories and their software delivery workflow. And take away some learnings from them. If you are eager to know more about Middleware OSS, check out this quick live demo.
Also read: Getting Started with Middleware Open Source
How did I go about understanding their software delivery process?
Of course, I checked their Dora Metrics including Deployment Frequency, Lead Time for Changes, Mean Time to Recovery, and Change Failure Rate.
Read what are Dora Metrics and how they can help with your software delivery process.
To understand AntDesign’s Engineering Pipeline, we should first understand their nature of work. What do they do primarily?
Where Ant Design Spends Their Time?
Features – 25%
Building new components and functionality
Think of these as new "furniture pieces" added to the catalog, like when keqingrong introduced quarter precision to DatePicker. These features keep the library relevant and versatile for evolving use cases.
Why it's good:Keeps the library fresh with new ideas.
Encourages adoption by solving real developer needs.
But:
- Spending only 25% on features may not be enough to stay ahead of user demands.
- Fixes – 45%
Squashing bugs and fine-tuning behavior
With nearly half of their time spent on fixes—like RubuJam tackling issues in imageTest.tsx—it’s clear the team is focused on quality control. A stable experience is crucial when thousands of apps rely on Ant Design components.
Why it's good:
Prevents user frustration with buggy components.
Demonstrates commitment to reliability.
But:
- Are too many bugs coming through? If 45% of the work involves fixes, it could indicate growing complexity that makes maintenance harder over time.
- Documentation – 30%
Writing and optimizing user guides and examples
Documentation might sound boring, but it’s a lifesaver. For instance, wanpan11 improved the description of the Modal’s static methods: docs: Optimize Modal static method operation description—something that helps developers quickly understand and use the components.
Why it's good:
Great docs = fewer support questions from users.
It reduces onboarding time for new developers.
But:
- If almost a third of the effort is on documentation, is the library getting too complex for developers to understand without extra hand-holding?
Understanding Ant Design’s Work and Performance Metrics
After analyzing the nature of their work, we’ve got a good idea of where the team’s focus lies. Now, let’s dive into their key performance metrics to see how well they’re doing.
How They’re Performing: First Response & Merge Times
Ant Design’s first response and merge times are well within the benchmarks laid out by the 2023 State of DevOps report.
First Response Time:
July: 4.62 hours
August: 6.39 hours
September: 7.68 hours
This quick response rate ensures that contributors stay motivated and engaged. A great example is the PR by coderz-w to fix the drag-and-drop upload delay, which was promptly reviewed by li-jia-nan
Timely feedback like this keeps the momentum going, encouraging developers to actively resolve issues and continue contributing.
Merge Time:
July: 0.96 hours
August: 0.45 hours
September: 0.73 hours
These numbers are impressive! Merging pull requests (PRs) in under an hour suggests a well-coordinated and efficient process. When teams merge code quickly, it reduces bottlenecks and allows new features and fixes to be released promptly.
So, Why Is Their Cycle Time Still High?
Despite fast first responses and quick merges, Ant Design’s cycle time—the total time it takes from starting work on a task to its completion—was:
July: 7.46 days
August: 9.14 days
September: 10.25 days
These numbers are slightly above benchmark expectations, which raises the question: Why is their cycle time lagging behind despite such quick responses and merges?
Possible Reasons for High Cycle Time
- Complexity of Work
Many PRs might involve more complex tasks, such as feature development or architectural changes, which take longer to finalize.
For example, introducing feat(DatePicker): add quarter precision by keqingrongisn't just a simple tweak—it involves testing, design considerations, and careful integration into the broader system.
- Multiple Iterations and Review Loops
Even though the first response and merges happen quickly, a PR might go through several iterations—including back-and-forth feedback and code adjustments—before it’s finalized. This can add to the overall cycle time.
- Prioritization of Fixes over New Features
Since 45% of their work focuses on fixes, it’s possible that new features or low-priority changes get delayed while the team tackles more urgent bugs and issues.
- Dependency Waiting Times
Some PRs may depend on other tasks or external resources (like design feedback or product decisions), causing them to sit idle for a while before being completed. This idle time contributes to the longer cycle time.
- Documentation and Post-Merge Tasks
A good portion (30%) of their efforts goes into documentation, which may extend the cycle time. Even after code is merged, follow-up tasks—like updating user guides—can keep the PR technically "open" for reporting purposes.
Also read: VS Code Dora Metrics: Reveals Smooth Cycle Time Smooth; Raises Red Flags on Lead Time
How Ant Design Can Improve Their Cycle Time: Suggestions from Their Own Playbook
Ant Design’s quick first responses and rapid merges are impressive, yet their cycle time remains slightly above industry benchmarks. The good news? They can borrow tactics from their own successful practices to bridge this gap.
1. Apply the “Modular PR” Approach to Complex Tasks
What they do well: Ant Design encourages smaller, modular PRs for bug fixes and feature updates, which keeps the workflow smooth.
Suggestion: For larger features, such as introducing quarter precision in the DatePicker, break them into smaller, interdependent PRs. By merging foundational parts earlier, the team can reduce waiting times and chip away at complexity step-by-step.
2. Shift Documentation Updates to Parallel Workstreams
What they do well: Their commitment to documentation (30% of their work) ensures high usability and developer satisfaction.
Suggestion: Documentation updates can sometimes extend cycle times if tied to code releases. To fix this, decouple documentation tasks and run them in parallel to code changes, or merge docs incrementally.
3. Automate Follow-Ups and Reduce Idle Time
What they do well: Their CI/CD pipeline ensures quick merges by automating checks and tests.
Suggestion: Extend automation to include reminders for pending PR reviews or dependent tasks. Idle PRs waiting for external feedback can be flagged early, reducing unnecessary delays in the cycle.
4. Leverage Fast Feedback Loops for Complex PRs
What they do well: Ant Design provides timely feedback on most PRs, fostering active contributor participation.
Suggestion: Create milestone-based feedback checkpoints for larger tasks. Instead of reviewing everything at once, reviewers can offer insights at critical stages—avoiding backlogs and rework at the end.
5. Prioritize High-Cycle-Time Tasks
What they do well: They handle bug fixes promptly, but some feature-related PRs may take longer.
Suggestion: Identify tasks with the longest cycle times (like complex features) and make them part of sprint priorities. Actively tracking high-cycle-time PRs can ensure they don’t slip through the cracks.
6. Expand Contributor Collaboration Channels
What they do well: Collaborative reviews like the one between coderz-w and li-jia-nan keep engagement high.
Suggestion: Introduce pair programming or co-authoring practices for larger PRs. This enables contributors to share responsibility, speed up review cycles, and reduce waiting times.
Ant Design's Astonishing PR Numbers: 267,252,220 Merged! What’s Driving This?
One thing that jumps off the page when looking at Ant Design’s GitHub repo is the mind-blowing number of merged pull requests (PRs): 267,252,220. Numbers like that aren’t just a reflection of regular work—they tell a deeper story about the team’s workflow, community, and strategy.
So, let’s break down what’s fueling this incredible activity.
1. A Large and Active Developer Community
Ant Design isn’t just maintained by a small team—it has a thriving open-source community around 2190 developers.. With so many developers contributing fixes, new features, and enhancements, the sheer volume of PRs reflects the power of community-driven development.
- Why it matters:
A big community means more ideas and faster problem-solving, but it also requires excellent management to ensure PRs are reviewed and merged efficiently. The active participation of contributors like keqingrong and codesignist in feature development shows how vibrant the ecosystem is.
2. Incremental and Modular Development
Ant Design follows a modular development approach, meaning changes are made in smaller chunks. Rather than bundling multiple fixes or features into one massive PR, contributors submit incremental PRs to keep things manageable and reduce the risk of breaking existing functionality.
Why it matters:
Smaller, more frequent PRs improve the quality and maintainability of the codebase.
This strategy ensures faster reviews and merges, as each PR tackles just one thing—whether it’s a feature, bug fix, or documentation update.
3. High Focus on Bug Fixes and Maintenance
As mentioned earlier, 45% of their work is spent on fixes. The number of merged PRs reflects the constant maintenance and upkeep required to keep the library running smoothly. A large, well-used library like Ant Design can accumulate a lot of minor bugs or edge cases over time, resulting in a high volume of small fix-related PRs.
Why it matters:
Each of these fixes adds to the merged PR count, creating the impression of relentless activity.
Timely merges, such as the folder upload fix by coderz-w, show that contributors are encouraged by fast feedback loops, resulting in even more contributions.
4. Documentation and Non-Code Contributions
The 30% spent on documentation also contributes heavily to the number of merged PRs. Developers constantly improve user guides, examples, and API descriptions to make the library easier to use. In open-source projects, non-code contributions like these are just as valuable as bug fixes or new features—and they get tracked as PRs too.
Why it matters:
Frequent documentation updates inflate the PR count, but they’re crucial for usability and onboarding new developers.
It shows that Ant Design values clarity and ease of use, which strengthens their reputation in the community.
5. Well-Managed CI/CD Pipeline and Merge Process
Ant Design’s ability to merge PRs within hours indicates an efficient CI/CD pipeline. Automated tests, continuous integration workflows, and dedicated reviewers ensure that PRs don’t sit idle. The short merge times of 0.45 to 0.96 hours suggest that the project team prioritizes keeping the queue moving.
Why it matters:
Quick merges encourage contributors to submit more PRs, knowing their efforts won’t get stuck in limbo.
A healthy pipeline means Ant Design can release new features and fixes continuously without delays, driving up the merged PR count further.
6. A Culture of Collaboration and Iteration
Finally, a big reason for such a massive number of merged PRs is likely the collaborative culture within the community. PRs often go through multiple iterations, where contributors improve code based on feedback, resulting in several rounds of commits and merges.
Why it matters:
This iterative approach fosters continuous improvement, but it also inflates the overall PR count.
Each small enhancement, refactor, or follow-up gets logged as a separate PR, reflecting the ongoing collaboration.
Ant Design: Speedy, Sleek, and Almost There—But Can They Crack the Cycle Time Code?
Ant Design's ability to merge millions of PRs speaks to a powerhouse of community-driven development, but it also reveals some growing pains. Their rapid first response and merge times show they’ve nailed the mechanics of speed—but speed isn’t everything. With cycle times slightly above industry benchmarks, it's clear there's room for tightening the bolts.
The good news? They have all the right tools already in place—like modular development and a responsive CI/CD pipeline. What’s missing is a bit of prioritization finesse and a sharper strategy for tackling complex tasks. Ant Design needs to treat large feature development like IKEA treats a flat-pack couch—break it into small, manageable sections that slot together seamlessly.
Also, shifting documentation to parallel workstreams might be just the boost they need to smooth things out. With fewer bottlenecks and a focus on clearing complex PRs faster, they’ll bridge the gap between “almost there” and “ahead of the curve.” Their numbers are already impressive, but with these tweaks, Ant Design can shift from being just productive to unbeatable.
If you find these learnings interesting, we’d really encourage you to give a shot at Dora metrics using Middleware Open Source. You could follow this guide to analyze your team or write to our team at productivity@middlewarehq.com with your questions and we’ll be happy to generate a suggestion study for your repo — free!
Also, If you’re excited to explore these insights further and connect with fellow engineering leaders, come join us in The Middle Out Community and subscribe to the newsletter for exclusive case studies and more!
Did you know?
The name "Ant Design" is inspired by the concept of ants working together as a team. It emphasizes collaboration and efficiency, reflecting the library's modular design approach.