“Just add an if”
You’re talking about a new feature that’s being planned and prioritized to the dev-team. It’s straight-forward enough, but you sense that it’s latching on yet another feature to an existing long chain of functionality. The team has some reservations to expanding the feature chain even more before doing some adjustments to how it’s been architected to keep this maintainable. That’s when you hear from the product owner: “Just add an if…”.
Perhaps you’ve heard these words during a discussion with a product owner or a business user. They’re looking at you, dumbfounded that you’re making such a big deal about this edge-case. “All you need to do is this thing for most users, and this other thing for the others…How hard can it be?!” they say. This person probably doesn’t comprehend the technical choices involved. Nor the fact that writing rules in software is as much about what can’t happen as what can happen.
So you ask yourself: “Does this solve the immediate need, and does it also fit into the bigger picture?”, “Which stage of the development cycle are you in?”, “how well-known is the domain?”, “Is there a hard deadline to consider?”, “What is and the maturity of the team? Are they capable of refactoring this later?”.
In our eagerness to deliver something of value to end users, we sometimes forget our professional obligation. We are software developers who develop solutions that solve the needs of users. Part of delivering a solution is also to consider long-term maintainability. We should have the integrity, as professional software developers, to say we cannot get a feature done in time because we want to deliver something of quality.
So when you sit down to add yet another feature to that ever-growing solution. Do you spend the time and take the steps needed to maintain that quality, or do you “just add an if”?
What do you do when confronted with “just add an if”? Share your experiences by reaching out to me directly with your thoughts, questions or criticisms. Or leave a comment below.
Originally published on Coding With Empathy