3 ms·

I think an important qualifying question is: how does your team/company deal with failures? Is there some other carrot/stick that incentivizes developers to beh

I think an important qualifying question is: how does your team/company deal with failures? Is there some other carrot/stick that incentivizes developers to behave this way? There's certainly a rational argument to be made that a project's progress is important and lines of "acceptable quality" should be drawn somewhere, but people are often not rational and respond to other things, and that's probably where your problem lies, IMO. For example- I used to work in a team that maintained an enterprise UNIX kernel, and we had a space shuttle - like culture of obsessive failure prevention using meticulous process and checks, because the cost of a failure could mean [m|b]illions of dollars at our customer sites. I now create startups, and the incentives are the absolute opposite- I need to get _something_, _anything_ out the door as soon as possible because the most important question I need to answer is "does anyone want this?" The reasons for either approach are not technical, and the source of your frustration, I suspect, is deeper than "convincing developers" (though I look forward to hearing what you have to say). EDIT: this post also expands a bit on the carrots/sticks I was referring to above: https://www.verica.io/inhumanity-of-root-cause-analysis/ https://www.verica.io/inhumanity-of-root-cause-analysis/

ericathegreat 7y 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.
- dkersten 7y ago
  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.

ericathegreat 7y 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.

dkersten 7y ago
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.