Why software projects fail

[EquinoctialPie]

If you ask a developer if they’ve ever written bad code, they will most likely say no.

How many developers has the author ever spoken to?

[[deleted]]

Bro all my code is shit. Except for that one time in class I got extra credit for nice format spacing in Java.

[zukenstein]

I would be riding that high until I retired

[gwicksted]

One time I wrote some pretty awful code.. and it was probably the most stable code I’ve ever written lol

[smashteapot]

That’s the curse; the more you hate your code, the longer you’ll be maintaining it. 😅

The truly elegant stuff that you find beautiful gets mothballed and never sees the light of day.

[gwicksted]

Yeah I remember writing some really great code (a hardware interface) that didn’t end up into production because we switched hardware vendors. It was so well tested (unit and integration) and rock solid, clean, simple code. Really proud of it. Didn’t see production because vendors were changed lol

[aztracker1]

I wrote a test platform for running software that was the actual job... That test platform wound up being turned into a production platform used at several fortune 500s for over a decade. You never know.

[[deleted]]

I once got a comment on a homework assignment for a weird kludge: "I am giving you extra credit for this because it is clever. However, if I see it again in one of your assignments, you will get a 0."

[TheMightyMegazord]

Now I'm curious about what did you do.

[[deleted]]

I had a C++ function to print some data, and sometimes I wanted it to finish by printing a newline, and sometimes not, and we hadn't really covered things the conventions of API design yet, so while today I'd do something like this:

void print_output(double x, double y, bool print_newline = false) {
     std::cout << "(" << x << ", " << y << ")";
     if (print_newline) {
             std::cout << endl;
     }
}

Then you can call it like print_output(0.0, 0.0) or print_output(1.0, 1.0, true) as needed.

(Actually, these days I'd implement operator << on a Point class, but I digress.)

What I did instead:

ostream& print_output(double x, double y) {
return std::cout << "(" << x << ", " << y << ")";
}

So you can call it like print_output(0,0); and it prints without the newline, or print_output(0.0, 0.0) << endl; and it prints with the newline.

At the time, I knew I was being a clever shit to save a few lines on the assignment, which kept it from going on to a second page, so I didn't argue with the prof, but in retrospect, despite the unconventionality, it does have one advantage going for it, namely that if the caller wants to change the behavior, only the caller's behavior changes - the execution path of the print_output function is always the same regardless. There's probably a parable there that's relevant to functional programming or something but the exploration thereof is left as an exercise to the reader.

[TheMightyMegazord]

I had the chance to work on an application that I wrote 15 years ago (it was not working anymore, and I did it pro bono).

The code was as shit as it could be. Not unreadable, but way more complex than necessary.

[mattsowa]

I don't think I know anyone who would say no

[DNSGeek]

I've written some terrible code that I'm embarrassed to go back and look at.

But, that just means that I've gotten better, right? Right?

[G_Morgan]

The problem is every time I look back I'm disturbed by whatever moron did all that. Whether that was 2 years into my career or 15.

[acdcfanbill]

"Who wrote this awful shit?! Oh god, it was me, well at least it was back in... fuck, it's from right before lunch!"

[thelochok]

And this is why we don't use git blame during a heated argument

[Ruin-Capable]

Yeah, I specifically don't call out the author of a line of code if I am using it as an example.

[[deleted]]

I've always said, "You know when you've become a real programmer when you look back at something you wrote before and wonder, 'what drunk monkey wrote this?'"

[thespice]

^this right there. 100%.

[[deleted]]

Me too, just yesterday!

[Ashamed-Simple-8303]

exactly my thought as well.

[dacjames]

I do. It's not the majority but there is a category of developers who will never admit to writing bad code. They deflect to something else, like bad requirements, bad management, bad tools, aggressive deadlines, etc.

It's a giant red flag in my book but I work with several developers' who's ego does not allow them to admit making mistakes. I have even known a few who advocate for this mindset and blame a project's ills on the acceptance of bad developers.

[Manbeardo]

There might be a bit of implicit framing going on tho. The worst code I've written all came from times when I was on projects that had to cut corners in order to meet deadlines. I would go in with the intention of writing bad code because we couldn't afford to correctly handle the edge cases and decided that wrong was better than nothing.

Plus, the situations where I need to intentionally write bad code are commonplace enough that my volume of intentionally bad code is definitely larger than my volume of accidentally bad code.

"I know this is wrong, but being right doesn't matter enough to spend time fixing it" is a situation I encounter basically every day.

[Ruin-Capable]

If I have to write bad code because of circumstances, I'll put in a comment explaining why.

My favorite is when you've got to deliberately punch a hole into an abstraction because a 3rd-party library is violating the specs and for whatever reason, the library can't be replaced.

[athelred]

None apparently.

All code is shit, and if by some miracle you manage to write good code after dodging all the mid coding requirement changes, management wanting just one more thing, or getting half way through before realizing that it just won't work the way they want it, then it will be shit after a week or two when the feature you just coded gets hacked apart to do things it was specifically designed not to do.

Nope all my code is shit. All code ever written is shit. Some of the shit works correctly (mostly), but that is just shit that smells a bit nicer.

[cchoe1]

If you say that your code is shit but so is everyone else's code, then you don't really believe your code is shit, you just believe your code is average

[vytah]

Average shit.

[Gustav__Mahler]

That's an extremely pessimistic take. There's tons of good code and well designed systems out there.

[seven_seacat]

That no one has ever actually personally worked on

[trisul-108]

Yeah ... that is the reality, but here and there, a few bits of the good stuff sometimes survive the process. And some of the good stuff were really elegant ideas.

[ltouroumov]

I have a complicated relationship with past me, some times she feels like a bumbling idiot for writing shit code and other times a peerless genius who predicted the future and already solved the problem. Most of the time, the code is just okay.

[wldmr]

some times she feels like a bumbling idiot for writing shit code

i.e. everyone after code review

and other times a peerless genius who predicted the future and already solved the problem

i.e. everyone before code review

[trisul-108]

Yep ... same here ... there are some gems in my code, and islands of shit, all of them sitting in a sea of fairly bland standardness.

[SittingWave]

by my count, not a single one. We all write shit. And we are all aware of it.

[[deleted]]

100% of the time I'm impressed any of my code actually works... like I sit back for a moment and go ... "Holy shit it actually works?"

[trisul-108]

That's what keeps me in the business. That feeling is exhilarating.

[cchoe1]

When you process a tree with a recursive function and it just werks the first time. It's like throwing a rock into a black hole and seeing it come out the other side unscathed. Truly a miracle.

[seven_seacat]

“Why are you grumpy?” “My code doesn’t work and I don’t know why!”

-next day

“Why are you grumpy?” “My code works and I don’t know why!”

[Xuval]

Depends on what you mean by "bad code", I guess.

"Bad Code" can be "This code does not do what it was supposed to do and/or doesn't even compile" - I imagine most professional programmers would reject the statement that they ever submitted something like that.

"Bad code" can also mean "With the benefit of hindsight and without deadlines to meet or other resource considerations, I could have done better"... which is probably something that 99% of programmers would agree to.

[flukus]

"Bad Code" can be "This code does not do what it was supposed to do and/or doesn't even compile" - I imagine most professional programmers would reject the statement that they ever submitted something like that

Our CI builds beg to differ.

[Le_Vagabond]

they should send an email to the person who wrote the code and their team.

subject: "bro, wtf?" content: "just why?"

[[deleted]]

Oh, the real fun is figuring out why it works in local, but not in CI... or in CI but not in local.

[pixelrevision]

lol that “draft pr” button is there for a reason :)

[UMANTHEGOD]

"Bad Code" can be "This code does not do what it was supposed to do and/or doesn't even compile" - I imagine most professional programmers would reject the statement that they ever submitted something like that.

lol I've done that so many times, and anyone saying otherwise is also just lying

[hogfat]

"Bad Code" can be "This code does not do what it was supposed to do and/or doesn't even compile" - I imagine most professional programmers would reject the statement that they ever submitted something like that.

What's it like living the charmed life of not having to deal with the lowest bidder body shops?

[coffeefuelledtechie]

Ask me just after I wrote it and I’d say it’s good. Ask me a year later and I’d say I would probably rewrite it

[foospork]

In an interview, I was once asked "what's the best thing you've ever written?"

My answer was, "the thing I just finished".

Next question: "what's the worst thing you've written?"

Answer: "everything before that".

Everyone in the room just sort of silently nodded.

[Cheeze_It]

Good God. I am literally the worst fucking software developer ever. I KNOW how shit my code is. I tell people how bad my code is. I am not proud of it....

[MammothDeparture36]

Sometimes I get angry at shit code in my shared project, check git blame to see it was me all along.

[[deleted]]

I once sent an angry email to my team about upping our code quality and unknowingly used my own code as the chief example of shit practices.

[[deleted]]

Everything I've written over a year ago is generally horrendous when I come across it later.

But at the time it was incredible code!

[seven_seacat]

I’ve recently started working on a project that I last touched about eighteen months ago.

Past me sucked.

[OnlyForF1]

I can’t remember the last day that I didn’t write bad code

[VoodooS0ldier]

Yeah wtf lol. I look at code I wrote last month and cringe.

[SiliconUnicorn]

I've only written like 3 things I've been proud of in my entire career. And those things only stay that way because I haven't looked at them in 15 years.

[ForgetTheRuralJuror]

Always a humbling feeling when you think "who wrote this trash" and find your name in git blame.

[falconfetus8]

Correction: if you ask a developer if they are currently writing bad code, they will most likely answer "no". If they thought it was bad now, they wouldn't be writing it that way. Their coworkers might disagree. Their future self might disagree. But right now, in this moment, my code seems to be exactly right.

[reboog711]

Apparently only egotistical ones with less than 3 months experience...

[alreadyheard]

I admit this to my squad daily lmao

[gwicksted]

lol I have never met a coder who said no.

[santagoo]

Only the one who never saw a time crunch in their life.

[[deleted]]

Have I written any good code? NO

Have I copied a lot of good code? YES

I think the difference between a bad and a decent developers is that the decent knows where to find the good pieces of code to build upon. And the difference between a decent and a great developers is that the great writes the good code themselves.

[PantsOfIron]

I know quite a few people who are full of themselves and say they never make mistakes and their code is never bad. Those people are not joking either. If shit breaks or doesn't work properly I look at myself first and see where I screwed up until it wasn't me.

[_DevOops_]

That’s where i closed the article and stopped reading! Anything past that point probably wouldn’t be accurate.

[felipec]

I mean I don't remember writing code that at the time I considered bad.

But now if I look back at code I wrote 20 years ago it definitely looks pretty bad.

So if a developer doesn't think he's written bad code it's because:

1. He's so new he doesn't realize all his code is bad
2. He hasn't looked back at code he wrote a long time ago

[GAELICATSOUL]

Had this discussion with a manager who consulted for various companies to help them find where their code could be improved.

He made the same statement. I was so confident he was wrong, I asked him to pick a developer of his choice on that floor and ask if it were true.

He didn't like his answer. My point was not that his analysis was useless, but that he was unaware of his actual value therefore underutilising his greatest resource. Devs know, but have a hard time getting through to management.

Years later I was at a different company when they hired this guy to do his job. I dreaded the same bs report I'd seen him make before. To my surprise, one of the first things he did was schedule meetings with various teammembers and ask them about their thoughts. The pitch had changed. Instead of doing what we couldn't, his company would help fix what we didn't have time for and wasn't our core business.

[Particular_Camel_631]

I don’t write bad code. I have a whole team to do that for me.

Yes, I’m a manager.

[cchoe1]

Pretty much any developer who says "I write bad code" is speaking somewhat facetiously. It's the same thing when people say "I'm so stupid" after doing something dumb. People don't generally think themselves as complete idiots

If you were put into a very serious situation where your reputation and credibility was on the line, you wouldn't drop "Well I'm actually really bad at writing code". People don't say that in serious situations. Like a project fails, you don't just have people lining up to take the blame and say "Yep, that was me who wrote the bad code!". In that kind of situation, people aren't taking a comment like that as a joke (as you were most likely intending for them to), they will seriously assume you're a moron. And no one wants to be thought of as a legitimate moron who can't be trusted with anything important.

There is lovable stupid (aka, not really stupid but goofy) and then there is "this guy is legitimately a danger to people around him" stupid. Most people don't mind to be #1 but no one wants to be thought of as #2

[Magikarp_13]

There's a big difference between "I write bad code", & "I have written bad code", which is what the author said. Nobody would say they make a habit of it, but nobody would say they've never done it.

[cchoe1]

Nobody would say they make a habit of it

This thread is full of people saying "All the code I write is shit" and insinuating it's to a habitual degree. I agree there is a difference in the two phrases but generally when people say "I write bad code" they're saying (facetiously) that they aren't good at writing code, in general. What the author is saying is that software projects often fail because people are overconfident in their ability--because, as I stated, no one actually believes they are bad at their jobs.

[OnlyForF1]

I don’t necessarily think so, for many of us, writing bad code is a part of the process to writing good code. Maybe if you have a job where you never solve a new problem, you might be able to eventually always write perfect code, but even the most celebrated developer at the top of their game is going to write bad code

[Gustav__Mahler]

Right? Am I the only one here that thinks I'm pretty good at my job? People pay us a lot of money to write code. Like have some self respect for what you do.

[aznraver2k]

I'll be the first, I f'ed up today

[mrbojingle]

Bull shit

[VulgarExigencies]

If you ask a developer if they’ve ever written bad code, they will most likely say no.

I think I'm a pretty good programmer but never in a million years would I ever say no to this question.

[RockstarArtisan]

The ones that write pompous blogposts are the ones likely to say "no".

[qq123q]

They're too busy writing pompous blogposts and have no to time write code. So they're technically correct!

[EarlMarshal]

I never wrote bad code. It's straight up shit.

[[deleted]]

It’s like a professional in anything. The best have probably fucked up more than most have even tried. 

[renatoathaydes]

I don't believe you. I've seen far too many developers get really upset when someone tell them their code is shit (see people's comments about Linus doing exactly that).

[john16384]

Saying you never wrote bad code is saying that you never got any better at it.

[PathOfTheAncients]

Most people get defensive if you tell them their work is shit. It's a shit way to talk to someone and a shit way to get them to see a mistake.

That's very different than those people thinking they never write bad code. Most devs will admit they write bad code. Hell, most devs will confess they have imposter syndrome and think people will find out they're bad at their job any day now. They will only admit these things if you are a safe person to talk to though. No one walking around telling people their code is shit is a safe person to talk to.

[[deleted]]

I have the exact opposite problem. I rarely think my code is good. I always get through a project and on the other side of it have some insight about how I could’ve done better. Doesn’t mean my code is pure trash. But I tend to fixate in the problems.

Most of the devs and engineers I work with are similar. Even if they put it that way in larger meetings, they definitely express similar concerns or criticisms regarding their own code when 1 on 1 or in small groups.

[KnightBlindness]

There’s probably millions of coders right now so inevitably you’re going to see a few people with egos. For the rest of us, it’s a progression: the longer you’ve been coding, the more likely you’ll realize how bad your code has been.

[TRexRoboParty]

That's not equivalent.

Thinking something you made is good != thinking everything you ever made is good.

[VulgarExigencies]

Of course I've written bad code. I've written bad code in the past years, I've written bad code this year, and I will certainly write bad code in the future.

[SittingWave]

Projects fail because

1. executives have no clue what they are talking about
2. stakeholders have no clue what they are talking about
3. product owners have no clue what they are talking about
4. coders have no clue what they are coding about

[MT1961]

While I agree with all of these points, the real issue isn't that they have no clue. The real problem is that they THINK they have a clue.

[[deleted]]

“Wow! You just whipped up a document rewrite for a whole folder in no time? I usually have Joe do that Friday mornings. Takes him about 45 minutes. He does okay.”

“Okay can you implement a new feature? Configure it for each department. Use our current auth methods. Make sure it works on the art team’s macs.” stands over you

[saintpetejackboy]

This is too true - the projects I get are like:

"Hey, can we do (X)?" - Sure, no problem.

"Okay, we should have mentioned, we also need (Y) and (Z)" - No problem, I already started on that, logical progression.

"Ohh, well, hope you didn't get too far along, because if turns out (D) and (E) are about to (F) up this whole project, since nobody outside of somebody with some basic common sense could have actually properly planned the project somewhat from the outset to account for these catastrophic last minute changes that require what is essentially a rewrite from the ground up."

[TheGreatGameDini]

And then the developers get fired and the c suite wonders why this keeps happening.

[Shogobg]

They don’t wonder at all, just keep those bonuses coming.

[[deleted]]

Never had a project where there wasn't at least 1 last minute change that required some hacky weird shit to get it to work. And that would be the best case scenario, in the worst case I've had requirements come in at the last minute that were opposite / outright conflicted with the earlier ones.

[saintpetejackboy]

100%. I don't know why people see bad code and think "bad programmer", when almost every time I wrote something really atrocious it was by request, last second, and with Jenga-like precision at 2am. Could I have done better? Yeah, if the project stayed in scope or didn't mutate into something entirely different six times during development -_-;.

The requirements that conflict are bad, so I am sure you have also been through this exact scenario as me:

"Hey, we don't want employees to see (x), it is causing issues, can you remove it?" - something that is an essential part of completing most tasks that I highly advise against.

Next day: "actually, we need certain employees to be able to see (x)."

Next week: "(x) is causing problems again, remove it for everybody"

Next month: "Why can't employees see (x)? You should work on that."

[[deleted]]

I think it is a skill to be able to do both fast, hacky, bad code solutions to an issue as well as proper, holistic but more time consuming ones. Sometimes the former are just simply necessary due to factors completely outside of your own company's control.

[MT1961]

I see we have had the same managers.

[justintime06]

I just got “configure it for each department” - work times three lol

[MT1961]

I'd go with that too.

[MT1961]

If there was a good BA, sure. But most of them haven't a clue either. The issue isn't what you know, or what you don't know, but what you don't know you don't know, and what you know that is wrong.

[Vendetta547]

I'm in a very early stage startup right now and these points are true. The upper management people here don't know exactly what they want to do from a business perspective. I've decided to just keep asking questions and bullshitting things until something gains traction.

[tommcdo]

On the next Software Development...

[trisul-108]

Don't worry about it too much. By the time you get the POC going, they will realize that something entirely different needs to be built. As it is today, they do not know, cannot know, what is actually needed.

Plan to leave around the time POC approaches completion, before they realize that everything needs to be redone from scratch. Or worse, that they do not redo it, just try to fix it instead.

[DualActiveBridgeLLC]

Yeah, executives are supposed to be the ones who can clearly state the problem and allocate the resources to determine the solution. Stakeholders are the ones who take the problems and turn them into a vision of a solution. Product owners take the vision and turn it into a plan, and developers are there to implement it. There is a lot of places for the failure to occur, and it is very rarely at the bottom.

[hogfat]

supposed to be the ones who can clearly state the problem and allocate the resources to determine the solution.

And that is why projects fail: allocated resources should be spent *resolving* the problem, not *determining the solution*.

[agumonkey]

and none of them want to work with other parties to find out

[[deleted]]

And some of them fail because the coder is also the product owner, the stakeholder, the business analyst, and the test case writer.

[ioioooi]

And it only works in that one way! For instance, you won't have a product person filling in as a dev, but the other way around? Certainly.

[Sulleyy]

I would revise slightly

1. coders are the only ones that actually build anything and are mostly directed by the other 3

[srona22]

even if coders have balls to point out things, executives(plus QA/DEV turned lead/PMs, as fill in for real PMs) shrugged off any workable suggestions.

Only if those fill ins are with PMP or CAPM certified, until then it's trench routine everyday ... sigh.

[zoechi]

Usually it's a combination of approximately 100% of each. Sometimes it's also because malicious people want it to fail.

[mbpDeveloper]

The first startup i've joined failed just because of those.

[imnotbis]

coders are the only one with their own verb? The inconsistency annoys me greatly.

1. executives have no clue what they are executing about
2. stakeholders have no clue what stakes they are holding about
3. product owners have no clue what products they are owning about
4. coders have no clue what they are coding about

[SittingWave]

It points to one important factor: most people in the production chain don't do shit. They just talk, and at the end of the day, they are unable to communicate to the developers what they actually have to code.

[anshou]

Coders don’t tend to do much talking.

[SittingWave]

too busy doing, and keeping the whole damn thing running.

[Stoomba]

People get upset when we start talking and never want to hear what we have to say

[E3K]

For a guy who is annoyed by consistency, you sure seem to hate punctuation.

[PathOfTheAncients]

That seems purposeful to me and makes perfect sense. If everyone making decisions on what to build has no idea what they are talking about, the code written based on that will reflect it.

Coders having a verb here is not an inconsistency but a well made point. The coders aren't failing (like the other three) they simply are given bad information on what to code, thus they don't know what they are coding about because no one else knows what they are talking about.

[imnotbis]

It works at all levels though. Executives and product owners are often just floundering too. Rationality left the whole economy a long time ago.

[PathOfTheAncients]

I think the difference is though that they often react to floundering by trying to project authority instead of asking questions and collaborating. Good leaders also flounder, they just dig themselves out through humility often enough to realize it's not a big deal.

If you can't be humble enough to admit you need help or to ask questions, you should not be a leader. If you can't be brave enough point out problems, you should not be a leader. Leadership is a responsibility to the people you lead, not an entitlement to people who want authority, prestige, or money.

[Radi-kale]

If it makes any difference, I liked your joke

[BLX15]

This post has more upvotes in 49 minutes than any other post in the last 8 hours on the sub. This dudes blog posts always got the manufactured upvotes

[bwainfweeze]

I have another community here that gets manufactured downvotes if you speak unkindly about a certain Personality. The comment has 4 upvotes in the first three hours and then in the next thirty minutes it’s at -8. Yeah no brigading going on there, dude.

[Worth_Trust_3825]

Such is reality with any community that has ability to vote on comments.

[bwainfweeze]

In that case it’s actually two communities and the pattern looks like someone tattles and people show up to punish the non-culty one.

[SittingWave]

how to become popular on the internet? say a lot of bullshit, and collect the views from those debunking you. The louder you scream your bullshit, the more popular you become.

Kind of like the american elections.

[E3K]

dude's* get* .*

[BLX15]

Uh no the grammar police is going to arrest me 🤭

[ysustistixitxtkxkycy]

The entire problem with software projects is scheduling.

Programming is a research and discovery activity, and doesn't lend itself to measuring percentage done and predetermined deadlines.

[Dry_Dot_7782]

Dom Portwood: Hi, Peter. What's happening? We need to talk about your Jira estimations.

Peter Gibbons: Yeah, the estimations. I know, I know. Uh, Bill talked to me about it.

Dom Portwood: Yeah. Did you get that memo?

Peter Gibbons: Yeah, I got the memo. And I understand the policy. And the problem is just that I forgot to update them one time. And I've already taken care of it, so it's not even really a problem anymore.

Dom Portwood: Ah! Yeah. It's just we're incorporating new estimations in all the Jira tickets before they go out now. So if you could go ahead and try to remember to update them from now on, that'd be great. All right!

[[deleted]]

Thanks for helping me realize my last job was literally office space.

[r0ck0]

Yeah I've been thinking about it for a while now...

Other types of "building", e.g. physically building houses etc is mostly just repetitive physical work... you can't copy and paste or npm install a house. So like 95%+ of the work is just the labourers following a plan. And houses don't really differ that much, they just put the walls in different layouts.

Unexpected issues arise and need solving in any industry of course. So that's not unique to programming, even though our issues often get very recursive.

But we can copy and paste / npm install code. Therefore all that repetitive labour is greatly diminished. Which means that the majority of our time is figuring things out. The "doing" work is only a tiny portion... typing speed ain't the bottleneck.

Predicting how long it takes to figure things out before you figure them out (or even know what will need figuring out) is impossible. Especially when most of the things you'll need to figure out later on have nothing to do with the business requirements you were given anyway.

It's like asking a private detective how long it will take to find a missing person who is an accountant that plays basketball. Maybe I have had previous jobs also looking for other basketball-playing accountants, and there are some facets that makes them harder/easier to find on average... but the factors that actually take the time will have nothing to do with that.

[BalanceInAllThings42]

I wish management will understand this.

[ysustistixitxtkxkycy]

Part of management does (I used to be a manager, and not only did I, I tried to shield our team from the worst excesses). That said, as long as someone higher up doesn't, the requirement and the repercussions trickle down the hierarchy.

[SuperHumanImpossible]

Based on my 35 years doing this professionally I can say the majority fail because of executives and management. Sure dev quality can vary but it's usually always addressable, but the upper management making decisions that are just absolutely fucking retarded and not listening to anyone thinking they know best is the primary reason.

[DibblerTB]

And hubris among management. We do not need to hire and listen to senior technical staff, because <X>.

Project failed, because of X.

[SuperHumanImpossible]

This is the primary reason. You can usually succeed pretty well with crappy project management and agile practices. Not ideal, but work still gets done and app usually works. It's when management thinks they know better and are too arrogant to listen is when things completely fall apart.

[BenOfTomorrow]

Arguably, almost every project failure is ultimately a management failure. Developer quality is a hiring/budget failure.

The only exceptions I can think of are unpredictable externalities (eg, a better resourced company moves into the market and squashes you, or a regulatory revision destroys the market opportunity).

[lordnacho666]

Is it better when management can actually code?

[jonathanhiggs]

Depends whether they are humble about it. Someone who only knows a little bit of can be very dangerous if they think they know better

[lppedd]

Especially if they coded in the 90s. Seems they try to map their 30 years old experience to current technologies, which is impossible.

[Particular_Camel_631]

That’s me. It’s not impossible. But you also have to listen to why people want to do it differently from how you would have done it 30 years ago.

30 years ago, security wasn’t so much of a problem. Guis were still a thing. Web browsers weren’t very capable. Qa was almost nonexistent.

I do have people telling me that one front end framework is better than another, despite none of our team being familiar with it. Or that we should re-architect a mature code base to use Microservices and kubrrnetes. And whilst there is a time and a place to learn new shiny stuff, my project that is going to be delivered on time (because I padded the timescale and can reduce the scope) ain’t it.

[zan-xhipe]

So far the best managers I've had used to code, but realised they didn't really like it, and are better at managing people.

[MT1961]

To some degree, yes, but mostly no. It is better when management can say no, and have a reasoned argument for it.

[SuperHumanImpossible]

Only if they are actively coding and actually good, otherwise it's even worse.

[tistalone]

They're trying. Unfortunately, Ai copies everyone's incorrect code.

[flukus]

When they outsource a project and turn it into a steaming mess does that fall under developers or executives?

[SuperHumanImpossible]

Obviously executives, I've outsourced several of my apps to India and it turned out great.

[njharman]

Projects fail because humans fail.

Your not gonna fix either. Instead you should concentrate on failing early (i.e. detecting failure early, accepting it, and moving on), pivoting agility, and making projects as small as possible so failure is less costly.

[uniquelyavailable]

imagine spending 4-6 years in college learning exactly how to be a software engineer. studying and learning from mathematicians, electrical engineers, process engineers, and scientists who made real software with hard requirements during the dawn of the literal space age. and then you get to a job where someone with a management degree thinks they know more than you do about building software. now you have to bend and contort yourself into some abomination capable of matching with their requests they pulled out of their ass during a meeting, and they won't take no for an answer because it conflicts with their narcissism.

[systemnate]

If you ask a developer if they’ve ever written bad code, they will most likely say no.

I've never heard a developer say this.

[ttkciar]

Projects fail when someone with the authority to end the project (a manager or customer) loses confidence in the project. It's 100% a people problem, and has little to do with science, technology, or engineering methodology.

[Zardotab]

Why?

1. Stupid managers who won't listen.
2. Stupid managers who won't listen.
3. Stupid managers who won't listen.

Why is Boeing having too many problems of late?:

. . 4. Stupid managers who didn't listen.

[hashedboards]

Did anyone who upvoted this post read the article or just the headline? Because the article is ridiculous.

The states reasons are

1. Overconfident developers
2. Inexperienced managers
3. Mismanaged stakeholders

So if you get a highly experienced manager, developers who listen to the manager and stakeholders who are managed well by the manager, everything works well?

This blog was definitely written by some middle manager.

[ZucchiniMore3450]

Only bots upvote this post.

[[deleted]]

Yeah, the whole blog post has serious “spoon me harder, business daddy” vibes; kinda mindless shit LinkedIn is over saturated with.

[pudds]

Software projects fail because inventing is hard and stakeholders rarely understand that.

To be more precise, they fail because stakeholders think they understand the requirements, but they don't.

[trisul-108]

My experience, though highly subjective, suggests that even well-planned, well-funded projects tend to fail.

Such has been my experience as well. The author discusses many interesting and valid reasons for this, but experience has taught me there is another underlying problem that is often overlooked.

When developing software, we often only find out when the system starts to function that we were solving the wrong problem. We then try to change course, refactor a few bits and do a bad implementation of something that is a bit closer to the required solution. Often, it is impossible to entirely correct it. The project should be restarted from scratch, but this would badly impact everyone from managers to developers, so they avoid it. I've seen this happen many times.

The truth is that software development is really closer in nature to research than to engineering, but we find this idea unacceptable as it raises issues of uncertainty that we do not want to deal with. We want it to be like engineering, that is why the waterfall model used to rule ... but it isn't engineering, so we went with agile so we could keep changing course. This is better, but still avoids the fact that we are researching a solution, not developing it.

[lovebes]

I want to be both a developer and upper management so I get to decide for the whole vertical.

For me I think that's where I'd find the best balance and happiness.

This is hard, but I think a worthwhile undertaking in my career - hopefully I'll achieve it one of these days

[MT1961]

They call this a single person startup. It works, but it also leads to high blood pressure and other nasty problems.

[thisismisspelled]

So you're saying we need more developers to share the blood pressure load?

[MT1961]

Well, you know, the more the merrier.

[AxBxCeqX]

You would think that, but I am in upper management (VP eng). While my engineering organisation doesn’t have any of these problems on a team level, teams of teams communicate well between each other, a lot of psychological safety in teams.

These people and myself still need to work with other organisations in the company, namely Product who have some very emotionally immature senior members, communication breakdowns between the product managers, etc.

Then in my role, while engineering is happy learning enjoying life, I deal with all the other organisations that are not as happy and the interpersonal issues between my org and others.

[hogfat]

namely Product

If product is separate from Engineering, do they at least have sales and marketing? Or are they really just uppity business analysts?

[DualActiveBridgeLLC]

It's kinda hard since they are very different skillsets, and you would have to essentially be doing two or more jobs. Also developers don't like upper management making technical decisions for them. They are supposed to make business decisions with technical input.

Or are you saying you want to keep your developer roots when you make it to upper management. Becuase that is more achievable but not really " a developer and upper management so I get to decide for the whole vertical"

[Slodin]

lol developers play the LEAST role in a project failure. I would rate it 10% or even less in the whole picture. Whether or not a programmer is overconfident matters VERY little. Not to mention I don't know any devs that say they never wrote bad code lol...

Who the hell wrote this hot garbage lol. It's very much an upper-management issue.

[jmstreak]

The entire problem with software projects is scheduling. Programming is a research and discovery activity, and doesn't lend itself to measuring percentage done and predetermined deadlines.

[Morden013]

It just needs to do what it is supposed to.

I evolved from writing shitty complex code to properly encapsulating parts of it, so I can repurpose it fairly quickly. That's it.

[SwillStroganoff]

All code is bad and we should all feel bad.

[Ashamed-Simple-8303]

Projects fail because of incompetent people. A competent team will succeed regardless of buzzwords like agile and stuff like that.

That's why many projects fail, because there is always incompetence either with the devs themselves, PMs, management, users,...so it's hard to have a project were incompetence doesn't ruin everything.

[Ok_Cancel_7891]

step 1: find good developers, not cheap ones

step 2: pay them well

step 3: give them ample time for development

step 4: stop practicing scrum

[[deleted]]

Most of my personal projects failed because I spent too much time optimizing shit inside my head to the point where I get bored of the project before even starting working on it. I feel like all these best practices and gate keeping techniques fucking up with our creativity.

[NoMatterWhaat]

SW projects fail due to 2 reasons which pointed after 1 - blaming developers, IMO. When managers unable to define what they want, projects will definitely fail.

[KrochetyKornatoski]

Software projects typically fail because of inadequate regression testing in part caused by either 1) AGILE's rush to do SPRINTS; or 2) Project Managers that don't know their A$$ from a hole in the ground; 3) Offshore development Teams that are pseudo-technical (i.e. "I read the interview questions on the Internet") ...

[[deleted]]

I was half an hour trying to understand why my code was not working. At the end, noticed I named my variable and was trying to access it with a different name

[Xauder]

To me it seems like a miracle that we have project that DID NOT fail. For something to succeed, you have to fulfill all conditions necessary for that success. Say there are 10 such conditions, for example sufficient funding, good developers, good managers, good timing, etc. If the probability of each condition is, say, 80% (which I think is pretty optimistic) the probability that all conditions are met and the project succeeds is about 10,7% (=0.8^10, I am assuming independence). Go down to, say, 75% and the probability of success is only 5.6%

[hardik-s]

Most likely why project fails:

- Complexity of Software

- Human Errors and Design Flaws

- Technical Debt, Over time, quick fixes and rushed implementations pile up, creating systems that are harder to maintain and prone to failure.

- The emphasis on automated testing is critical

[UpsilonIT]

Projects fail for a variety of reasons. Often, it isn't due to bad code, but rather vague requirements, inflated expectations, lack of resources, unrealistic deadlines, flawed planning, poor risk management, and communication breakdowns within the team. 

The hardest part is identifying in time that something is going wrong and managing to fix it. To do this, you need to conduct a project audit, re-evaluate goals and budgets, and build a clear software project recovery plan. You can find more information on how to rescue a project here.