Month: February 2025

We are excited to announce that Hubtel is now ISO 27001:2022 certified! 

What is an ISO 27001 certification? 

The International Organization for Standardization (ISO) is an independent, global body that sets standards for best practices across industries. Among these standards is ISO 27001, the internationally recognized benchmark for Information Security Management Systems (ISMS). 

This certification provides companies with a structured framework for establishing, maintaining, and improving their information security management practices. 

For Hubtel, achieving this certification means we have implemented industry-best security measures to protect data, mitigate risks, and uphold the highest security standards in managing sensitive information.

We have been compliant with the previous standard, ISO 27001:2013, since 2020. With this latest certification, we have strengthened our security framework even further, ensuring continuous protection, resilience against evolving threats, and greater trust for our customers and partners. 

What does this mean for our Customers and Partners? 

Security has always been a top priority at Hubtel. This certification reinforces our commitment to safeguarding our systems, customer data, and partner information. 

1. Strengthened Security & Reduced Risks 

We have taken proactive steps to reduce vulnerabilities to cyber threats. With a robust system in place, we can swiftly respond to evolving security risks while ensuring our people, processes, and technology are equipped to handle potential threats. 

2. Protecting Critical Information & Assets 

We have prioritized securing critical assets such as financial records, intellectual property, employee data, and third-party information. Our centrally managed security framework ensures that all information—whether paper-based, cloud-based, or digital—is protected, confidential, and easily accessible when needed. 

3. Enhanced Efficiency & Cost Savings 

By optimizing security operations, we have improved efficiency while ensuring long-term cost-effectiveness. Our structured approach to risk management and resource allocation helps us maintain operational stability without unnecessary expenses. 

READ ALSO: Beyond Instinct: How the Code Confidence Index (CCI) is Transforming Code Quality at Hubtel 

With this certification, Hubtel joins a select group of global enterprises with world-class information security practices. Our customers and partners can trust that their data is handled with the highest level of security and compliance. 

For more details about our security measures, visit Hubtel’s Information Security Policy. 

You can also view our official ISO 27001:2022 certificate here.

Engineering is a craft. Writing code isn’t just about functionality—it’s about creating something maintainable, efficient, and scalable. Yet, for years, software teams have struggled with an age-old dilemma: 

How do we measure the quality of our code? 

Some say, “You know clean code when you see it.” Others rely on instinct. But here’s the problem: gut feelings don’t scale. Codebases grow, engineers come and go, and what seemed like “good code” one day can become a cautionary tale the next. 

At Hubtel’s Code Quality Team, we decided to tackle this head-on. We needed something more than intuition—something measurable, actionable, and scalable. And so, we built the Code Confidence Index (CCI)—not just to measure code quality, but to improve it. 

READ ALSO: From Snail Mail to Warp Speed: How Hubtel Rocketed Its Product Delivery 

Why Code Quality Matters (And Why We’re Tired of Fighting Bad Code) 

Let’s not pretend: bad code is a productivity sinkhole. 

• It slows down development cycles. 

• It makes debugging feel like archaeology. 

• It increases technical debt faster than a high-interest loan. 

On the other hand, high-quality code accelerates everything. Developers ship features faster, fixes are easier, and scaling is a joy rather than a death march. 

But there’s a catch: quality must be measurable. If we can’t quantify it, we can’t improve it. That’s where CCI steps in. 

Introducing the Code Confidence Index (CCI): The Metric That Changed Everything 

Imagine trying to lose weight without a scale. You might feel healthier, but without numbers, how do you know you’re making progress? 

That was our approach to code quality—until we built CCI. 

CCI is a single, actionable score that evaluates the overall health of a codebase. Instead of vague statements like “This module feels messy,” we get hard data: 

✅ Test Coverage: Are we testing enough of our code? 

✅ Bugs & Vulnerabilities: How many issues are creeping into production? 

✅ Code Complexity & Smells: How maintainable is our architecture? 

✅ Duplications & Framework Hygiene: Are we following best practices? 

CCI doesn’t just diagnose issues—it guides improvement. A repository with a score of 58/100? It tells us exactly where to focus. A score of 80/100? It confirms our hard work is paying off. 

And it’s not just theoretical. We tested it, and the results were game-changing. 

Case Study: The Repository That Went From 58 to 80 

To see if CCI really worked, we applied it to a backend repository with a score of 58/100. 

The Diagnosis: A Codebase in Trouble 

Breaking down the numbers, we saw the problems clearly: 

• Test Coverage: 25% (far too low) 

• Bugs: 12 major issues 

• Security Vulnerabilities: 8 flagged risks 

• Code Smells: 250 problematic patterns 

• Cognitive Complexity: 2500 (dense, difficult-to-read code) 

• Duplicated Lines Density: 12% 

This wasn’t just an abstract number—this was friction in every commit, every merge, every deployment. 

The Plan: Smart, Targeted Fixes 

Rather than an endless refactor, we took a strategic three-phase approach: 

Phase 1: Boosting Test Coverage (2 Weeks) 

• Added unit tests for core logic 

• Implemented integration tests for key workflows 

• Increased coverage from 25% to 50% 

Phase 2: Fixing Bugs & Security Issues (1 Week) 

• Addressed 7 critical bugs 

• Fixed 5 high-priority security vulnerabilities 

• Reduced bug count from 12 to 5, vulnerabilities from 8 to 3 

Phase 3: Cleaning Up the Code (2 Weeks) 

• Refactored complex methods 

• Removed redundant, duplicated code 

• Reduced code smells from 250 to 100 

The Outcome: A Healthier, More Maintainable Codebase 

After just a few weeks, we saw dramatic improvements: 

• Test Coverage: 50% (+100% increase) 

• Bugs: Reduced from 12 to 5 

• Vulnerabilities: Down from 8 to 3 

• Code Smells: Dropped from 250 to 100 

• Cognitive Complexity: Reduced by 60% 

• Duplicated Lines Density: Cut in half 

Final CCI score: 80.3—a 38% increase. 

Beyond the numbers, the real impact was felt in daily development. PRs merged faster, debugging was smoother, and the once-dreaded repo became far easier to work with. 
 
Sustained Improvement Without Development Disruptions 

One of the greatest advantages of integrating CCI into our workflow is that it allows us to improve code quality without derailing development cycles. Traditionally, code quality initiatives often mean halting sprints for refactoring, leading to delays and frustrated teams. With CCI, quality improvement becomes a continuous process, not a roadblock. Engineers make incremental enhancements alongside feature development, ensuring that we build, ship, and refine without grinding productivity to a halt. 

How CCI is Reshaping Our Engineering Culture 

This wasn’t just about fixing one repository. CCI is changing the way we think about code quality. 

1. Code Quality Sessions That Matter 

We turned code reviews into structured quality sessions, where senior engineers review repositories, provide insights, and mentor teammates. Instead of nitpicking syntax, we now discuss real structural improvements. 

2. Data-Driven, Not Opinion-Driven Engineering 

Discussions about code quality are no longer subjective debates. Instead of “This feels off,” we now say: 

• “Our test coverage needs to improve by 15%.” 

• “We have too much cognitive complexity in this module—let’s refactor.” 

3. A Culture of Continuous Improvement 

Rather than vague aspirations to “write cleaner code,” teams now have clear targets. Engineers actively track their CCI scores, making quality improvement a habit, not an afterthought. 

READ ALSO: Scaling an Engineering Team from 16 to Over 100 in Less Than 4 Years: Hubtel’s Journey, A Tale of Growth, Innovation, and a Whole Lot of Coffee 

Beyond the Score: What This Means for Software Engineering 

CCI is more than a metric. It’s a philosophy. 

• It shifts quality from subjectivity to objectivity. 

• It turns code maintenance from a chore to a structured process. 

• It creates a feedback loop where engineers can see their progress. 

Software engineering isn’t just about building features. It’s about building sustainable systems that stand the test of time. And for that, code quality can’t be left to gut feelings. It needs to be measured, tracked, and continuously improved. 

Final Thoughts: Measuring What Matters 

For years, developers have debated what makes good code. With CCI, we no longer need to guess. We have the numbers, we have the process, and we have the results. 

So the next time someone says, “You know clean code when you see it,” ask them this: 

“Do you have the data to prove it?” 

Because at Hubtel, we do. 

Remember when dial-up was the only way to connect to the internet? Slow, painful, and enough to make you throw your computer out the window? That’s what our software builds felt like at Hubtel for a while.

Our codebase was exploding like a teenager’s growth spurt, and our build pipelines, which used to be pretty snappy, were suddenly resembling rush hour traffic on a Friday night.

Instead of popping champagne for new features, we were tapping our fingers impatiently, waiting for builds to crawl across the finish line. Talk about buzzkill. 

Our once-smooth process had become a tangled mess of resource crunches, technical hiccups, and enough waiting time to make a sloth look speedy.

Imagine this: every time we tweaked something, even a tiny thing, we were rebuilding the entire digital city, even if we’d only moved a single lamppost. Clearly, something had to be done. 

READ ALSO: Beyond Instinct: How the Code Confidence Index (CCI) is Transforming Code Quality at Hubtel 

The Roadblocks: Where We Hit Snags 

Resource Constraints & Costs: Think of scaling build pipelines like hosting a massive potluck. You want enough food for everyone, but you don’t want to end up with mountains of leftovers and a hefty grocery bill. We needed a smarter way to feed our builds without breaking the bank. 

Queue Times & Delayed Builds: Picture a Black Friday sale, but for code updates. With multiple teams pushing changes constantly, our build queues became a bottleneck of epic proportions. Developers were left twiddling their thumbs, releases were getting pushed back, and frustration levels were reaching boiling point. 

Mono-Repository Woes: Mono-repos are like giant filing cabinets – great for keeping everything organized, but a pain to search through. Unlike smaller, more focused repositories, our massive mono-repo meant we had to analyze everything, even for minor changes. It was like searching for a single grain of sand on a beach. 

Technical Hurdles: Beyond just throwing money at the problem (which, let’s face it, we didn’t have an endless supply of), we faced some serious technical challenges. Optimizing selective builds and automating dependency tracking required a serious overhaul of our build scripts. 

Our Game Plan: How We Turned It Around 

Instead of just adding more servers (because who has a money tree growing in their backyard?), we decided to get clever. We focused on automation, intelligent build detection, and resource optimization to transform our pipelines into high-speed bullet trains. 

1. Smart Build Detection: We built a system that could pinpoint exactly which parts of our code were affected by any changes. Think of it as a Sherlock Holmes code. This involved creating a kind of map of our codebase, understanding the relationships between different parts of the system.

Then, when a change was made, our system could trace its impact, identifying only the areas that needed to be rebuilt. This meant we only had to rebuild what was absolutely necessary. No more rebuilding the whole city for a single lamppost!

2. Selective Project Builds & Publishing: Our pipeline now intelligently detects changes and only builds and publishes the relevant projects.

This drastically reduces build times and eliminates wasted effort. We essentially taught our system to be a discerning chef, only preparing the dishes that were actually needed. This involves a few key steps: 

a. Change Detection: Our system analyzes the code changes and identifies the specific files that have been modified. 

b. Project Mapping: It then uses a map of our project dependencies to determine which projects are affected by those changes. Think of it like a spider web, where each project is a node, and the connections represent dependencies. When one node is touched (a file is changed), the system can trace the ripples to see which other nodes (projects) are also affected. 

c. Dependency Tracking: It goes a step further, understanding which projects depend on the affected projects. This ensures that even if a project itself hasn’t changed, if a project it relies on has, it will still be included in the build. 

d. Selective Building: Finally, it uses this information to build only the necessary projects and their dependencies, skipping everything else. 

e. Commit Message Influence (Targeted Builds): But we took it a step further! Developers can now directly influence the build pipeline using their commit messages. This is incredibly useful when a developer knows exactly which projects need to be built and wants to bypass the automatic dependency detection.

For example, if a developer makes a small, isolated change and wants to quickly deploy just that one piece, they can add a special tag or keyword to their commit message to specify the exact projects to build.

This gives developers fine-grained control and further optimizes the build process, allowing them to focus on precisely what needs to be released, instead of relying solely on the system’s automated dependency analysis.

This “targeted build” feature is like giving developers a “fast pass” for their builds, allowing them to jump the line when they know exactly what they need.

Build Pipeline comparison 

3. Automated Code Quality Checks: Every new pull request now gets a thorough code quality check-up, ensuring we maintain high standards without slowing things down. 

4. Automated Containerization: Say goodbye to manual Dockerfile management! Our pipeline now automatically containerizes our applications, making deployments smoother than a hot knife through butter. This involved automating the entire containerization process: 

a. Dockerfile Generation: Our system automatically generates Dockerfiles for each project, based on its dependencies and configuration. It’s like having a master chef who knows exactly what ingredients and instructions are needed for each dish. These Dockerfiles define the environment in which our applications will run. 

b. Dependency Management: The generated Dockerfiles include instructions for installing the necessary dependencies, ensuring that each container has everything it needs to run. 

c. Image Building: Our pipeline then automatically builds Docker images from these Dockerfiles. These images are like packaged versions of our applications, ready to be deployed. 

d. Registry Publishing: Finally, these images are automatically pushed to container registries (like Amazon ECR or GitHub Container Registry), making them readily available for deployment.

Automated Containerization Process

5. Dynamic Resource Allocation: We built a system that automatically scales our computing power up during peak build times and scales it back down when things are quieter.

This ensures we have the resources we need without wasting money. It’s like having a thermostat for our builds, keeping the temperature just right. 

The Payoff: Faster, Smoother, and More Scalable Builds 

The results? Let’s just say they were pretty impressive. Build times plummeted, queue times were slashed, and we significantly optimized our resource usage, saving a considerable chunk of change.

Developers went from dreading build times to getting feedback almost instantly. It was like going from snail mail to warp speed! 

READ ALSO: Scaling an Engineering Team from 16 to Over 100 in Less Than 4 Years: Hubtel’s Journey, A Tale of Growth, Innovation, and a Whole Lot of Coffee 

Lessons Learned: Smarter, Not Harder 

Our journey taught us a valuable lesson: optimizing build pipelines isn’t about throwing money at the problem; it’s about being smart, innovative, and always striving to improve. Through automation, selective builds, and dynamic resource management, we’ve built a system that’s not just good – it’s awesome. 

At Hubtel, we’re not resting on our laurels. We’re constantly looking for new ways to make our builds even faster and more efficient. Think of us as software chefs, always experimenting with new ingredients and techniques to create the ultimate recipe for speed and efficiency. 

So, if your builds are feeling a bit sluggish, take a page from our book. With the right strategies, even the most complex build systems can be transformed into lean, mean, speed machines that fuel innovation and seamless product delivery.