Operations | Monitoring | ITSM | DevOps | Cloud

Internal Developer Portals (IDPs) have increasingly found their way to the center of engineering operations. As the new engineering system of record, IDPs make it possible to align and enforce standards while unlocking safe developer self-service. Of course, oft-cited benefits like removing friction and improving consistency might feel intangible or even duplicative to other tools in your stack. So how should engineering leaders think about evaluating IDPs?

Infrastructure as code (IaC) tools enable the automation of cloud infrastructure and IT infrastructure deployment and management. These configuration management tools allow DevOps teams and development teams to define computing infrastructure resources as code in configuration files, use version control systems like GitHub, and deploy infrastructure consistently across different environments, from on-premises data centers to cloud services.

Anyone who has been reading this blog or who has worked at Cortex can tell you that we are quite passionate about Developer Experience (DevEx). But just what is DevEx, and how does it relate to onboarding new developers? It's a fair question, since the word can mean different things in different contexts. We are even on the record as saying that definitions are necessarily vague to allow for DevEx being inherently subjective to a given environment.

The engineering macro-climate is in crisis. Market dynamics have put increased pressure on teams to ship faster in order to stay competitive, while budgets are under significant scrutiny. At the same time, the advent of new tools and architectures promising high-velocity, collaborative development increasingly lack the implementation structure needed to preserve their benefits. As a result, onboarding is stalling out, incidents are up, and deployments are down.

Software migrations are an inevitable part of running any technical organization. Whether you're upgrading your database, moving to a new cloud provider, or modernizing legacy applications, migrations are necessary to keep software efficient and secure. Unfortunately, migrations are often a slow and messy processes, dragging across months and potentially years. They are difficult to coordinate, from both managerial and technical standpoints, and often cause a lot of frustration for those involved.

Engineering onboarding comprises more than just allocation of credentials and orientation to top tools. Depending on staffing, capacity for resource and permission allocation, and maturity of self-serve tooling, it can take weeks or even months for engineers to contribute their first meaningful PR—a common measure of "onboarding completeness." So how should engineering leaders think about optimizing their processes to improve developer effectiveness, velocity, and confidence?

We know speed to market matters—now more than ever. Bill Gates said in the nineties that “if you don’t meet customer demand quickly enough, without sacrificing quality, someone else will.” But software quality also matters, affecting everything from customer loyalty to developer experience. Poor quality causes immediate issues like bugs and crashes, as well as building technical debt and making updates needlessly hard.

Software quality isn't just about defect density; it embodies the reliability, performance, and security that underpin digital trust and user satisfaction. But measuring software quality can be as challenging as defining it. In this post, we'll demystify the complexities around assessing software quality and provide actionable insights for you and your software development team.

Developers are working to faster development cycles, having their productivity measured in embarrassing ways and facing burnout due to poor productivity metrics. Detecting and preventing bugs in this environment is challenging for developers, but code quality is too important to ignore or leave to chance. Improving code quality requires smart metrics, not just more measurement. The quality of your code is foundational to your software, and ultimately your products and company.

On December 31, 2008, all the Microsoft Zunes around the world stopped working. The development team hadn’t properly accounted for the Leap Year, and when the year changed over, everything broke. On February 29, 2024, card payments in a Swedish grocery chain went down, payment terminals in New Zealand gas stations crashed, and an EA Sports racing game was rendered unplayable for the day.