Peter Eysermans

A startup CEO recently asked: “Can I just hire someone to document everything and be done with it?”. The company had grown from a team of 1 to 12 in just a year. Initially, the product was built with a focus on shipping features quickly—a practical and necessary choice

Rebuilding a system is never my first choice, but sometimes it’s the only viable path forward. For example, years ago, many teams built web applications using ASP.NET Web Forms. Fast forward to today, and with no straightforward upgrade path to .NET Core, rebuilding becomes inevitable. A rebuild isn’

We have to work together with this external partner. They have no idea what they're doing. I frequently hear software development teams express their frustration when working with external partners: * "These people have no idea what they're doing." * "How can such a tiny request take weeks?" * "Why are they so

Trust between the engineering team and business stakeholders is crucial. Asking for 6-months of non-feature work erodes that trust. Non-technical people become suspicious and think they are being tricked. The technical team must communicate with the business to educate them on the consequences of ignoring technical improvements. Start signalling possible

Structuring your development team is a crucial decision. Do you hire specialists or full-stack developers? The full-stack reality check * Full-stack is actually T-shaped. Every full-stack developer has their sweet spot, a technology where they truly excel. * It's about breadth, not depth. They possess broad knowledge across technologies, not encyclopedic expertise

Have you ever heard this from a stakeholder? "The engineering team keeps talking about technical debt. I don't understand what they mean, and all I get is vague technical explanations." Unclear requests to handle technical debt create a rift between stakeholders and engineering teams. The technical leader must bridge this

"You have a hard problem? Sarah will fix it!" As engineers gain experience and tenure, they inevitably face increasingly complex challenges. It's the nature of our field—the toughest problems land on the desks of our most seasoned professionals. While it's gratifying to hear, this praise can mask a hidden

I've previously discussed the consequences of technical debt. Let's explore an aspect that's often invisible to non-technical stakeholders: quality degradation. The 3 Steps of Quality Degradation 1. It starts small: adding a few lines to spaghetti code or postponing an update. 2. Non-technical stakeholders are unaware of the problem until

“Our product should be perfect, with zero bugs! Also, our budget is limited.” The truth is that quality isn't an exact science. Perfection comes at a cost. What to consider when determining the level of quality: 1. Industry context: Highly regulated sectors demand rigorous QA. For non-critical products, speed to

Mobile app development has unique challenges, particularly when publishing on the Google Play and Apple App stores. Recently, I encountered a situation highlighting the importance of foresight when creating a new app. The Challenge A client reached out because their Android app had been removed from the Google Play Store