How often do developers fail at their task?

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

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.

I fail until I figure it out. If you don't stop trying, you don't fail.

Now, time may get in the way. And money. But the idea that some software problem is too hard to solve is strange.

I get stuck and ask for help from a more experienced team member all the time. Is that failing?

I don’t think I’ve ever declared defeat on a ticket, but I’ve gotten significant help many times.

I don’t think I’ve fully completed a sprint in over 5 years.

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

I am the OP. Failing would be - not being able to do it on their own.

I keep making the same silly mistakes from 20 years ago...

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.

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).

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.

I fail nearly ALL the time as a programmer … at home.

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

Be completely unable to do a thing? Not very often, abd probably suggests a systemic problem rather than a personal one.

Fail to do exactly what a manager orcustomer thought should happen? 99% of the time.

Many, many times a day. Many times an hour. But then we debug it, fix it, and move on.

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.

once per employer