In your experience, when a developer is assigned a task, how often do they fail? I know my own failure rate, but I'm curious what it is across the industry.
For some definition of fail, I fail often. E.g. my last prediction was I could create an administrative frontend for one of our complex systems in a couple of days and failed to do so, because frontend is not about business, but about how much of a webdev-punk you are.
I think that “fail” needs some examples/definitions here.
Depends on the definition. By design I fail a few times before I succeed whenever I'm debugging something, go for the low hanging fruit first.
The task as a whole though is usually successful given enough time. I've not been completely stumped yet (web dev/sysadmin is pretty trivial work, kinda bored of it honestly but the bills need paying) and can usually figure out a workaround in the worst case.
It weirdly helps that there's nobody for me to ask lmao. I'm the one others ask when they're stuck, when I get stuck I just gotta look into it more until something gives. "I'll figure it out" comes up a bunch.
I can't claim 100% success as I don't get to control everything I spend my work time on but of the things I have the time/resources it's not too far off.
Sometimes I fail a sprint because estimations weren't correct. Sometimes I fail a task technically because the task can't be done with the tools I have or the time I'm given, or would produce code too brittle or rotten to justify doing.
When I have more of a free hand I usually can get something working though. But it's not like I'm creating new algorithms or anything.
I think for anyone who candidly tries and has a good understanding of programming, they won't fail if given reasonable time.
The problem is always the marketing, management, and c-suited who have never written a line of code in their lives but want to dictate the terms of a feature.
An example might be a new frontend page
On the surface there is a business use case for it, a client wants it asap. The sales and marketing get that feedback and push it along to the developer to estimate...now here is the issue
Sometimes it's easy and no big deal, you write a backend model that wraps a hopefully existing db table and a frontend to wrap that model. Hopefully you have some wireframes or even a crude mspaint example of what they expect. Sometimes you don't and just copy a similar page and adapt.
The issue comes when that isn't the case. Maybe the page they want ties six tables worth of data together and requires a mother of all stored procedures or a hard coded query in the backend somewhere. Maybe what they are asking has no symantic connection at all and you need to create six different lookup ID columns, maybe even what they want like a graph of complex data or a docx generated in JS is just a bad idea for page performance etc. Maybe the feature breaks the convention of your codebase entirely and becomes a security concern or requires a major package like react or flask to be updated to get a function that would simplify it. Any number of things can go wong and eventually do.
This all comes down to the company. At a good company developers and project managers have the freedom to express that the estimate for a feature or the scope or even rational for a feature is going to be complex and take time you will need to find. At big companies this means working on it while being in scrums or sprint meetings and quarterly meetings and brainstorming meetings and whatever the hell the sprint bingo or poker stuff is. A good management team will understand what they don't understand and give your team the bandwidth they need to do their job well.
At a bad company your estimate is ignored or shamed in some way and you are forced to lie which is often the case and say everything takes 2x as long to finish just in case there are crazy issues you didn't understand. The management will tell the cline yup front that a feature will only take a week before even talking to development estimating based on a similar ticket to snag a sale for themselves and when they are wrong they push that blame onto engineering to save their skin progress reports. If the feature doesn't make sense as described by the client to marketing and sales and you have no recourse then you end up creating bloated and needlessly complex software that is essentially designed by somewhat unnatural selection and over time you get random api endpoints and UI/UX sins that snowball into what we usually call "typical banking software" outlook is also an excellent example of this problem though.
Sadly the honest developers tend to go over budget or estimate at these companies and management typically only sees that as a data point in their tracking software and usually ask your micro-manager or PM to crack a whip without any context for why and how. Its invariably the engineers fault because every level beyond them has exponential disconnects as to what the true work of writing software requires in your codebase. They have no understanding of technical debt or limitations on front ends/backends.
Occasionally a new hire from college just can't cut it but I've never seen it happen because someone is genuinely not smart enough. If you just try in Ernest you will succeed somewhere but if you get fired for not delivering deadlines don't beat yourself up immediately, ask yourself what you were task to do and consider how realistic that was...and realize there are plenty of other jobs out there who will respect your opinion.
So reality didn't line up with someone's fantasy about when things would happen? Doesn't sound like a failure to me, sounds like someone needs to get their head out of the clouds when estimating.
In theory, task estimates should be done by developers. Of course, an estimate is not the same as the reality, but if you keep telling the average estimated time, you should underestimate about as often as overestimate. That means, you should do at least half of the sprints on time.
So if the developers keep underestimating the time consistently for years, something is wrong.
I am not saying it is necessary the developers' fault. Often the problem is managers making pressure on developers to provide shorter estimates. But I have also met overconfident developers, who keep believing that "this time it will be different, because this time it is actually easy... as opposed to all the previous times, when it merely seemed easy" over and over again. Or maybe you have a teammate like this, and then you start also underestimating your tasks, to avoid seeming incompetent compared to him during the planning sessions. (Yes, people who provide shorter estimates than you, and then deliver at exactly the same time as you, are usually perceived by the management as more competent. The make a better impression during planning, and not-worse impression on delivery.)
> In your experience, when a developer is assigned a task, how often do they fail? I know my own failure rate, but I'm curious what it is across the industry.
I guess it depends on how failure is defined.
If you're defining failure as "things take far longer than expected", then basically all of the time. And that's ok, because software development is different than building a house: there's no near-exact formula like you have in construction where you figure out the square footage of a wall to paint and can come up with a really good time estimate almost every time.
If you're defining failure as "we can't physically figure out any method to solve this technical problem even if we were given years to crack away at it" then I'd say not too common.
Also similar to building a house, a developer might get the job done but it fails inspection (QA). So the final completed job is not done without more work. Most dev teams bake in extra time to their estimates, expecting minor failures.
I purchased new construction once. They were putting up a thousand cookie cutter houses like ours in that neighborhood. And even that estimate missed the mark by more than 3 months. Even estimating building the same floor plan the hundredth time is hard!
Now imagine, you are tasked with building a house with no floor plan. You have to procure some materials last minute, and at least two of the materials you must create from raw materials. Occasionally, you have to remove structural parts of the house to account for changes to the requirements. Someone built their own power tool instead of using the out of the box nail gun, which injured a fellow worker and required replacement of drywall. The crew had a holiday, then it rained, then a shipment of materials was delayed. After your electrician recovered from the stomach flu, he was unable to wire the house for ceiling fans -- a late stage increase in scope from the customer -- because one of the workers wanted to learn a new technique for framing for the block and wire, which he read about on hacker news. When the construction is 95% complete, the boss asks the crew to go ahead and start on another build. Another month elapses, and the home is nearly done. Your office contacts the customer to schedule closing, only to discover that the customer changed their mind and got an apartment 6 months ago. All is not lost, however: your boss receives a bonus for a job well done, which he thanks you for. Good job! A few months later the home is found to be in violation of a recently ratified law making smart homes illegal in the county, but no one involved in its construction works there anymore so they'll each likely repeat the mistake at least once more.
Tried an approach that failed? Tried many approaches and gave up but retried months/years later? Someone asked you to do something impossible/stupid/conflicts with other requirements?
You never fail if you communicate along the way. Everyone fails..
At what point would you consider it a failure when an individual contributor cannot deliver work autonomously and constantly has to rely on his colleagues to any task. I'm not talking about clarifying questions or "hey i got stuck after doing XYZ and need some help" type of situation.
In that case I’ve never failed. This is not a value judgement around my work or what I deliver. Only that I’ve never had a thing with which I couldn’t figure it out and deliver it (eventually)
In contrast to some of the stories I see here, in my last job my team had a really strong track record of completing sprints as scheduled, but our product's architecture was doomed to fail from the start (we could've done it but it would've taken at least an additional year, by which time it would've been canceled).
26 comments
[ 3.4 ms ] story [ 74.3 ms ] threadI think that “fail” needs some examples/definitions here.
The task as a whole though is usually successful given enough time. I've not been completely stumped yet (web dev/sysadmin is pretty trivial work, kinda bored of it honestly but the bills need paying) and can usually figure out a workaround in the worst case.
It weirdly helps that there's nobody for me to ask lmao. I'm the one others ask when they're stuck, when I get stuck I just gotta look into it more until something gives. "I'll figure it out" comes up a bunch.
I can't claim 100% success as I don't get to control everything I spend my work time on but of the things I have the time/resources it's not too far off.
When I have more of a free hand I usually can get something working though. But it's not like I'm creating new algorithms or anything.
The problem is always the marketing, management, and c-suited who have never written a line of code in their lives but want to dictate the terms of a feature.
An example might be a new frontend page
On the surface there is a business use case for it, a client wants it asap. The sales and marketing get that feedback and push it along to the developer to estimate...now here is the issue
Sometimes it's easy and no big deal, you write a backend model that wraps a hopefully existing db table and a frontend to wrap that model. Hopefully you have some wireframes or even a crude mspaint example of what they expect. Sometimes you don't and just copy a similar page and adapt.
The issue comes when that isn't the case. Maybe the page they want ties six tables worth of data together and requires a mother of all stored procedures or a hard coded query in the backend somewhere. Maybe what they are asking has no symantic connection at all and you need to create six different lookup ID columns, maybe even what they want like a graph of complex data or a docx generated in JS is just a bad idea for page performance etc. Maybe the feature breaks the convention of your codebase entirely and becomes a security concern or requires a major package like react or flask to be updated to get a function that would simplify it. Any number of things can go wong and eventually do.
This all comes down to the company. At a good company developers and project managers have the freedom to express that the estimate for a feature or the scope or even rational for a feature is going to be complex and take time you will need to find. At big companies this means working on it while being in scrums or sprint meetings and quarterly meetings and brainstorming meetings and whatever the hell the sprint bingo or poker stuff is. A good management team will understand what they don't understand and give your team the bandwidth they need to do their job well.
At a bad company your estimate is ignored or shamed in some way and you are forced to lie which is often the case and say everything takes 2x as long to finish just in case there are crazy issues you didn't understand. The management will tell the cline yup front that a feature will only take a week before even talking to development estimating based on a similar ticket to snag a sale for themselves and when they are wrong they push that blame onto engineering to save their skin progress reports. If the feature doesn't make sense as described by the client to marketing and sales and you have no recourse then you end up creating bloated and needlessly complex software that is essentially designed by somewhat unnatural selection and over time you get random api endpoints and UI/UX sins that snowball into what we usually call "typical banking software" outlook is also an excellent example of this problem though.
Sadly the honest developers tend to go over budget or estimate at these companies and management typically only sees that as a data point in their tracking software and usually ask your micro-manager or PM to crack a whip without any context for why and how. Its invariably the engineers fault because every level beyond them has exponential disconnects as to what the true work of writing software requires in your codebase. They have no understanding of technical debt or limitations on front ends/backends.
Occasionally a new hire from college just can't cut it but I've never seen it happen because someone is genuinely not smart enough. If you just try in Ernest you will succeed somewhere but if you get fired for not delivering deadlines don't beat yourself up immediately, ask yourself what you were task to do and consider how realistic that was...and realize there are plenty of other jobs out there who will respect your opinion.
I don’t think I’ve ever declared defeat on a ticket, but I’ve gotten significant help many times.
So if the developers keep underestimating the time consistently for years, something is wrong.
I am not saying it is necessary the developers' fault. Often the problem is managers making pressure on developers to provide shorter estimates. But I have also met overconfident developers, who keep believing that "this time it will be different, because this time it is actually easy... as opposed to all the previous times, when it merely seemed easy" over and over again. Or maybe you have a teammate like this, and then you start also underestimating your tasks, to avoid seeming incompetent compared to him during the planning sessions. (Yes, people who provide shorter estimates than you, and then deliver at exactly the same time as you, are usually perceived by the management as more competent. The make a better impression during planning, and not-worse impression on delivery.)
I guess it depends on how failure is defined.
If you're defining failure as "things take far longer than expected", then basically all of the time. And that's ok, because software development is different than building a house: there's no near-exact formula like you have in construction where you figure out the square footage of a wall to paint and can come up with a really good time estimate almost every time.
If you're defining failure as "we can't physically figure out any method to solve this technical problem even if we were given years to crack away at it" then I'd say not too common.
Now imagine, you are tasked with building a house with no floor plan. You have to procure some materials last minute, and at least two of the materials you must create from raw materials. Occasionally, you have to remove structural parts of the house to account for changes to the requirements. Someone built their own power tool instead of using the out of the box nail gun, which injured a fellow worker and required replacement of drywall. The crew had a holiday, then it rained, then a shipment of materials was delayed. After your electrician recovered from the stomach flu, he was unable to wire the house for ceiling fans -- a late stage increase in scope from the customer -- because one of the workers wanted to learn a new technique for framing for the block and wire, which he read about on hacker news. When the construction is 95% complete, the boss asks the crew to go ahead and start on another build. Another month elapses, and the home is nearly done. Your office contacts the customer to schedule closing, only to discover that the customer changed their mind and got an apartment 6 months ago. All is not lost, however: your boss receives a bonus for a job well done, which he thanks you for. Good job! A few months later the home is found to be in violation of a recently ratified law making smart homes illegal in the county, but no one involved in its construction works there anymore so they'll each likely repeat the mistake at least once more.
You never fail if you communicate along the way. Everyone fails..
Fail to do exactly what a manager orcustomer thought should happen? 99% of the time.
Now, time may get in the way. And money. But the idea that some software problem is too hard to solve is strange.
This is how I advance at work … rapidly with my successes.
“A genius is often merely a talented person who has done all of his or her homework.” —- Thomas Edison