Hacker News new | ask | show | jobs
by ericathegreat 2497 days ago
This. Absolutely.

If something fails six months after release, who ends up paying the penalty?

Are your developers on-call for production issues? Will they be woken up at 3 in the morning, expected to solve customer issues caused by one of those corner cases? Or if it's someone else on call, will your developers experience the wrath of the person who _was_?

If a production issue occurs, does the person who produced that code get pulled off whatever new they are now working on, because "they're the best person to fix that issue"? Even if they've "moved on and up" and their new work is more interesting or prestigious than the project that has the issue?

Is their failure publicized across the whole business?

If data is corrupted because of a corner case, do your developers have to go through tedious processes to repair that data (with angry customers causing frustrated managers to breathe down their necks)?

Do they have to defend and justify to all of their peers why their code broke production because of a "corner case" that they were fully aware of and chose not to handle?

And even more importantly, if they build the 80% first, what guarantee do they have that you will let them write the last 20%, and not just move on to the next thing? Consider - if they build the corner cases first, they've guaranteed that they'll get all the scoped work done (because you won't ship without the other 80%), but if they front load that highly visible 80%, they will almost certainly get pulled off the project before they get to handle those corner cases.

All of these things are very strong motivators for teams to do exactly what you're asking them not to do. As a (presumably) product focused person, your reward happens as soon as your product is in customers' hands. You are rewarded for a product that is released quickly. But developers are frequently penalized for that.

When you ask your development team to focus on releasing incomplete software, you're asking them to treat _your_ success as more important than _theirs_.

That doesn't mean that what they're doing is necessarily right. You need to set up an environment where your teams' success is aligned to the thing you most want to have happen. Change the rewards and penalties in your company, and behavior will change itself.

Or, failing that, negotiate a compromise position between your desire to get something to market, and their desire not to continue paying the price for that speed for the rest of their tenure at the company.

1 comments

People also like to work on things that they can be proud of and incomplete software that ignores the edge cases often isn’t that and can be frustrating to work on for too long.