Engineering Principles

The Cruel Irony of Software Estimation Hofstadter’s Law states: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.” When I first read this, I thought it was quite funny. After reflecting on it for a while, it became a little less comical and a lot more real, because it perfectly captured every project I’d ever worked on. Ever. You know the drill: you estimate a period of time for a feature, user story, or bug, add a little “safety buffer” of a few hours or days (depending on the task), and somehow still find yourself running late, explaining to stakeholders why you’re not done yet. The law’s recursive nature - acknowledging its own existence yet still failing to solve the problem - is both hilarious and deeply frustrating. ...

Introduction to the Broken Windows Theory The Broken Windows Theory, introduced by social scientists James Q. Wilson and George L. Kelling in 1982, suggests that visible signs of disorder and neglect, such as broken windows, lead to more disorder and crime. The idea is that maintaining and monitoring urban environments in a well-ordered condition may stop further vandalism and escalation into more serious crime. I must confess, I hadn’t even heard of this particular topic until it was introduced to me by a Principal Engineer in a previous role who used to reference it a lot. At first, I thought he was just being overly enthusiastic, but as it turns out, he was right all along. His persistent reminders and detailed explanations eventually made me realize the importance of this concept. ...

Goodhart’s Law in Software Engineering Goodhart’s Law states: “When a measure becomes a target, it ceases to be a good measure.” This can have significant implications in a software engineering environment. Examples of Goodhart’s Law in Action 1. Code Quality Metrics Scenario: A team is measured by the number of lines of code (LOC) they produce. Outcome: Developers might write verbose code to increase LOC, sacrificing readability and maintainability. The focus shifts from writing efficient, clean code to simply increasing the LOC metric. 2. Bug Fixing Scenario: The team is rewarded based on the number of bugs they fix. Outcome: Developers might prioritize fixing easy, low-impact bugs to boost their numbers, while more complex, critical bugs remain unresolved. The metric (number of bugs fixed) becomes the target, overshadowing the importance of fixing high-priority issues. 3. Feature Delivery Scenario: Success is measured by the number of features delivered in a sprint. Outcome: The team might rush to complete features without thorough testing or proper documentation, leading to technical debt and potential issues in the future. The focus on quantity over quality can degrade the overall product. 4. Code Reviews Scenario: Engineers are evaluated based on the number of code reviews they complete. Outcome: Reviewers might rush through code reviews to meet their targets, providing superficial feedback instead of thorough, constructive critiques. This can lead to lower code quality and missed opportunities for improvement. Balancing Metrics To avoid the pitfalls of Goodhart’s Law, it’s essential to balance metrics with a holistic approach: ...