Why Software Projects Fail | Hacker News Reader

Why Software Projects Fail

vadimkravcenko.com

48 pointsbndr15 comments

> If you ask a developer if they’ve ever written bad code, they will most likely say no. I’m guilty of this as well. I don’t remember ever writing bad code; ...

What an utterly nonsensical article. Not a single developer ever said that.

Agree that this statement is way off, but the rest of the article is hardly "nonsensical." Did you stop reading here?

No. The full article does not make sense. As an example, I have never seen, in my 23 years of professional software development experience, overconfidence be a reason for a project's failure.

You've never seen the "we can rewrite this legacy system in a year" mistake? Because I've seen this at least 4 different times.

Good point. I've seen something similar to it, but it was a failure of the management, not developers. The management says "we painted ourselves into a corner and now we need to replace this legacy system with a modern implementation. It shouldn't take more a couple of years". The rewrite took almost 10 years to complete. If anything, the part that I would call as developers' failure was the inability to push back with realistic timelines.

I've seen it play out differently, with developers (especially seniors) pushing for their favourite tech. "We're gonna make the new system event based with Kafka", etc.

I literally just had to shoot this exact idea down this sprint.

Great developers in my experience are full of both humility and cynicism - it is the only logical reaction to the insanity of coding long-lived and large projects.

I think the prize is a competent team which can make important decisions through dispassionate discussions, and which otherwise trusts team-members to drive everything else independently - pulling support where needed.

Top 3 in my experience:

- Scope creep.

- Bad product market fit.

- Insufficient time / money / talent.

nailed it.

To that I would add - not identifying/doing core PoC's.

Only bad developers would state they don't do bad code.

The 3 reasons I've seen for failure :

1 - management want to add something to the requirements so they can "shine" and grow their career = why some almost never used basic crud internal app for 7 users is built with docker, microservices and redis.

2 - management don't want to take the necessary risks because they fear that might taint their career if it doesn't work = why we still have cobol code from the 60's

3 - incompetent people, I even found some saying about this "it only needs the bad person at the right place for wreck it" = don't get me started on that one.

My experience working in a large internet services company is that relatively few of our software projects fail, but about 50% of our software systems are failures—in that they deliver insufficient value and are deprecated within 1-3 years of their launch.

For such systems, I don't think there it's fair to assign a single point of failure, but typically the failure is correlated with a couple of factors:

- It was built by a team with a shallow understanding of the problem to be solved (and not enough time/interest/skill to get a deeper one)

- It was built by an org that was not stable enough to provide the long term support it needed to prove its value (1.0 is an important milestone, but 1.0 software will die on the vine without the support to get to 1.1, 1.2, and 2.0)

"Talent" obvious plays a role, but I feel it is hard to answer the question "is this team talented enough?" as compared to "does this team understand the problem well enough?" and "will this teams organization support them long enough?"

There should be a balance of short term and long term thinking and project management is the optimisation between the two.

My experience is that managers only think short term which makes SWEs defensive and be dogmatic about long term.

The the project fail.

Well written article focusing on essential big picture nuances that we should be aware of.

Overconfident developers w.r.t. a) Coding skills b) Learning new technologies c) Our abstractions d) External dependencies - Better thought of as developers underestimating the problem complexity. I think the Dunning-Kruger effect (https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect) is very much at play here since there is so much different and new out there that you are perpetually in a learning mode. Note that "In popular culture, the Dunning–Kruger effect is often misunderstood as a claim about general overconfidence of people with low intelligence instead of specific overconfidence of people unskilled at a particular task." I think that we cannot escape this but must learn to modulate it.

Inexperienced/Incompetent/Negligent Managers - The article points out some characteristics which i am sure we all can relate to. Only proper training can mitigate this.

Mismanaged stakeholders - Better thought of as Risk Factors/Management/Communications.

Reply on news.ycombinator.com