Lauren Craigie (Head of PMM at Cortex) is joined by Justin Reock, Head of Developer Relations at Cortex for a conversation about meausuring developer productivity.
Reporting from multiple engineering systems is crucial for maintaining the high velocity and quality standards required in today’s tech industry. However, creating reports can be challenging due to the need for deep technical expertise and aggregation of many separate systems worth of data.
In 2023 most engineering organizations have some way of measuring productivity. Metrics like story points and cycle time help us assess team-wide impact, while code coverage and commits tell us more about individual contributions. While we know these numbers don’t tell the whole story, we rarely hear about how to find the missing pieces. Or what to do next when we learn the culprit is poor testing practices versus bad design. What’s the plan for improvement? Where does it live, and who owns it?
From the Regulatory Lead to the Site Reliability Engineers (SREs) and development team, there are quite a few individuals involved in keeping a Financial Technology (FinTech) company compliant. And there are quite a few regulations to stay in line with: anti-money laundering (AML), know your customer (KYC), payment card industry data security standard (PCI DSS), the list goes on.
Engineering teams rely on certain metrics to assess their ability to deliver quality products, on time. This is a useful exercise, but execution has been lacking—with metric collation often handled via spreadsheet, or stand-alone tool. Neither approach is ideal for two reasons: 1) How—or more specifically where—metrics are collected silos them away from business context.
In an article titled The Worst Programmer I Know, Dan North, the creator of behavior-driven development, writes about a nearly fired developer he saved from the unemployment line. This developer consistently delivered zero story points, even though delivered story points was the primary metric for developer productivity at their (unnamed) software consultancy.
This blog is a summary of Frost & Sullivan's extensive report on Cortex as the recipient of the Technology Innovation Leadership award for North American Internal Developer Portals. Read the full report here.
Developers are builders by nature (and profession), so many take pride in building their own solutions to problems from first principles, often using tools developed in open-source projects. So as Internal Developer Portals (IDPs) increased in popularity, it should come as no surprise that interest in open source IDPs increased in kind. While we may not yet have a fully opensource IDP platform, in this blog we’ll cover the open source components and platforms used to build IDPs from scratch.
Improving software health, security, and operational maturity are continuous programs—you’re never really “done” maintaining standards of quality. But what if specific parts of that program feel more urgent? Maybe you want to ensure all software has a README file attached, and at least 1 reviewer assigned... by next month? Hey, you gotta start somewhere!
An Internal Developer Portal (IDP) is the engineering system of record for tracking, improving, and building high-quality software. From services and APIs to Kubernetes clusters and data pipelines—IDPs abstract away the complexities of ensuring software security, maturity, production readiness, and more—all using data from your existing tools.