Picture this: You’re in a meeting room where your SEO expert is explaining new URL generation rules for your Web Content Management System. The developers are nodding along, taking notes. Everything seems clear until someone asks the obvious question: “How do these new rules interact with what we’ve already built?”

Suddenly, everyone’s looking at each other. The SEO expert thought the developers knew all the existing rules (they’re in the code, right?). The developers assumed the expert had the complete picture of the URL generation system. What followed was the usual knowledge archaeology - everyone digging up fragments of what they could remember and trying to piece together the complete picture.

This isn’t just a communication problem—it’s a fundamental gap in how we approach domain modeling in enterprise environments. And I bet you’ve been in this exact meeting.

After exploring the basics of software estimation and understanding the key elements that make estimates valuable, it’s time to get practical. You know the theory, you understand what good estimates should provide, but now you’re sitting in your next sprint planning wondering: “Which estimation method should I actually use?”

As someone who’s wrestled with estimation challenges in different enterprise environments, I’ve learned that having a toolkit of proven methods is essential. Today, I’ll share my three go-to estimation approaches that have consistently delivered value in DevOps teams, along with some bonus tips that can save you from common estimation pitfalls.

I realize the irony here. As someone who’s spent years evangelizing TDD and helping teams embrace test-driven development, writing an article about reducing tests feels a bit like a fire chief recommending fewer smoke detectors. But here’s the thing: after working with countless DevOps teams across enterprise environments, I’ve learned that more tests don’t automatically mean better quality—they often mean the opposite.

What I’ve observed repeatedly is that comprehensive test coverage often becomes a maintenance nightmare.

I’ve watched brilliant teams spend more time babysitting brittle tests than actually delivering features. They achieve impressive coverage percentages that look great in reports but create a hidden tax on every code change.

After years of implementing TDD and evolutionary architecture in enterprise environments, I’ve identified four strategic approaches that help teams escape this trap. These aren’t theoretical best practices—they’re survival tactics born from real-world pain.

Like many software engineers, I’ve spent the last six months embracing AI coding assistants in my daily work. When GitHub Copilot and similar tools first entered our department, expectations were high. Management anticipated dramatic productivity increases, and many developers were excited about the promise of accelerated development cycles.

Six months later, I’m sharing my unfiltered experience - both the impressive wins and the frustrating challenges that are rarely discussed in the glowing case studies published by AI providers.

Quality Storming is a popular workshop format for brainstorming quality scenarios in software development projects. However, creating relevant quality scenarios from a quality model can pose a significant challenge to participants due to its abstract and generic nature. A risk-based approach offers an alternative, that provides a more concrete view of product quality, sharpening the perception of quality scenarios that are crucial for the product to succeed.

When I learned about TDD it boosted my productivity as a developer and made my professional life easier. By following this simple cycle, I was able to efficiently and effectively transform specifications into working software in an iterative manner. I’ve always wondered if there is something that supports the learning process in the same way, knowing it is also a crucial part of my job. As my career progressed, I accumulated practices that helped me speed up my learning. However, it wasn’t until I read the book “Get Better at Anything” by Scott H. Young that all the pieces fitted into a picture that worked for me: the Learning Loop.

The first article in this series covered the basics of software estimation and concluded that a systematic approach is preferable to wild guesses. But what are the key elements that make up a profound forecast, and how do they work? Those are the questions we will address in this article.

Getting asked about estimations was my worst nightmare when I started my career as a software engineer.Writing software was easy for me because I was familiar with design patterns, architecture styles, and principles in software engineering. But when it came to giving a forecast for a new project, I was lost. Where should I start? Where should I end? What principles should I follow and what methods can I use? To make matters worse, there were high expectations for a sound estimate. It was often crucial to the profit of my company. But how can I provide a forecast that meets all expectations and is profound at the same time?

After many years of reading articles and books on this topic and experimenting with different approaches, I came up with 10 basic tips that help me with this challenge. Here is what I’ve learned so far.

With the shift to DevOps product teams take responsibility for the overall reliability of a system. As a consequence they need a service level management that goes beyond merely measuring the availability and uptime of servers. Service Level Indicators and Objectives help them to achieve this by specifying and monitoring reliability from a user perspective. Together with methods from software architecture and domain driven design this approach can be seamlessly integrated into the accustomed development process.

It is exciting for me to learn a new programming language, since it provides me with the opportunity to solve common programming problems more efficiently. In my primary area of work, back office business applications, Domain Driven Design (DDD) is widely used. So, when I switched from Java to Kotlin, I was curious to see how my new main language applies to these patterns . My first step was to learn about implementation alternatives of value objects, a concept for modelling data in DDD.