That guy here. At a previous job, my pay and bonuses were tied to getting X new features added. I was incentivized to do the absolute bare minimum to get as many features "out the door" as...
In recent years I have been surprised to find that most dev teams I work with simply do not track these. These teams have an ocean of excuses: “We won’t ever fix it.” “That’s not my job.” “I don’t want to fix anything, I get rewarded for new features.” None of these is good enough to justify the low quality results that are produced by this approach.
That guy here.
At a previous job, my pay and bonuses were tied to getting X new features added. I was incentivized to do the absolute bare minimum to get as many features "out the door" as possible.
Sure there were bugs. We logged them. The project manager (who also was incentivized to ignore them) put them lower on the priority list than new features.
I could have spent time fixing bugs, sure. I would have been written up for not working on what was assigned. I would have missed out on pay. I would have been on the chopping block when it came time to tighten the belt.
Removing QA from the equation and incentivizing bad work is a management problem. The factory floor guys are incentivized to have lower numbers of bad creations. I am incentivized to spit out as many barely-working things as I can. Change incentives away from the fire hose of bullshit and you would see people happily working with QA.
I've had some talks between departments recently to figure out a way to improve ticket flow, because I don't think it should be up to a dev to decide to deprioritize bugsplatting and ignore real...
I've had some talks between departments recently to figure out a way to improve ticket flow, because I don't think it should be up to a dev to decide to deprioritize bugsplatting and ignore real user problems.
Though I guess it's easy if you deliberately ignore and run away from "janitorial" work by simply refusing to work with the same ITSM tools the rest of your business is working in. Just keep developing broken features for the upcoming sprint, deprecate whatever is causing the most issues, and ignore people asking for fixes as much as you can.
This isn't to say they do bad work, but they do incomplete work. I think this opinion piece really manages to touch on whatever the hell has been bugging me for a while now. There's just no testing, testing only means you get this pesky "accountability" you can't get rid of.
It's not a surprise to read this, it's not even something that took a while for our teams to figure out, but it's sort of cathartic to read something that seems to happen not just in our corp, but everywhere.
That guy here.
At a previous job, my pay and bonuses were tied to getting X new features added. I was incentivized to do the absolute bare minimum to get as many features "out the door" as possible.
Sure there were bugs. We logged them. The project manager (who also was incentivized to ignore them) put them lower on the priority list than new features.
I could have spent time fixing bugs, sure. I would have been written up for not working on what was assigned. I would have missed out on pay. I would have been on the chopping block when it came time to tighten the belt.
Removing QA from the equation and incentivizing bad work is a management problem. The factory floor guys are incentivized to have lower numbers of bad creations. I am incentivized to spit out as many barely-working things as I can. Change incentives away from the fire hose of bullshit and you would see people happily working with QA.
Ahhhhh the feeling when someone hits the nail on the head of “why can’t we deliver non-broken software” :)
I've had some talks between departments recently to figure out a way to improve ticket flow, because I don't think it should be up to a dev to decide to deprioritize bugsplatting and ignore real user problems.
Though I guess it's easy if you deliberately ignore and run away from "janitorial" work by simply refusing to work with the same ITSM tools the rest of your business is working in. Just keep developing broken features for the upcoming sprint, deprecate whatever is causing the most issues, and ignore people asking for fixes as much as you can.
This isn't to say they do bad work, but they do incomplete work. I think this opinion piece really manages to touch on whatever the hell has been bugging me for a while now. There's just no testing, testing only means you get this pesky "accountability" you can't get rid of.
It's not a surprise to read this, it's not even something that took a while for our teams to figure out, but it's sort of cathartic to read something that seems to happen not just in our corp, but everywhere.
And in other news, water is wet.