Ask HN: 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.
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.
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.
Now, time may get in the way. And money. But the idea that some software problem is too hard to solve is strange.
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.)
You never fail if you communicate along the way. Everyone fails..
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 that “fail” needs some examples/definitions here.
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
Fail to do exactly what a manager orcustomer thought should happen? 99% of the 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.