> While hardware folks study and learn from the successes and failures of past hardware, software folks do not

I've been managing, designing, building and implementing ERP type software for a long time and in my opinion the issue is typically not the software or tools.

The primary issue I see is lack of qualified people managing large/complex projects because it's a rare skill. To be successful requires lots of experience and the right personality (i.e. low ego, not a person that just enjoys being in charge but rather a problem solver that is constantly seeking a better understanding).

People without the proper experience won't see the landscape in front of them. They will see a nice little walking trail over some hilly terrain that extends for about a few miles.

In reality, it's more like the Fellowship of the Rings trying to make it to Mt Doom, but that realization happens slowly.

▲

avemg 6 hours ago | parent [-]

> In reality, it's more like the Fellowship of the Rings trying to make it to Mt Doom, but that realization happens slowly.

And boy to the people making the decisions NOT want to hear that. You'll be dismissed as a naysayer being overly conservative. If you're in a position where your words have credibility in the org, then you'll constantly be asked "what can we do to make this NOT a quest to the top of Mt Doom?" when the answer is almost always "very little".

	▲	Wololooo 6 hours ago \| parent \| next [-]
		Impossible projects with impossible deadlines seems to be the norm and even when people pull them off miraculously the lesson learned is not "ok worked this time for some reason but we should not do this again", then the next people get in and go "it was done in the past why can't we do this?"
	▲	RaftPeople 5 hours ago \| parent \| prev \| next [-]
		> And boy to the people making the decisions NOT want to hear that. You are 100% correct. The way I've tried to manage that is to provide info while not appearing to be the naysayer by giving some options. It makes it seem like I'm on board with crazy-ass plan and just trying to find a way to make it successful, like this: "Ok, there are a few ways we could handle this: Option 1 is to do ABC first which will take X amount of time and you get some value soon, then come back and do DEF later Option 2 is to do ABC+DEF at the same time but it's much tougher and slower"
	▲	marcosdumay 3 hours ago \| parent \| prev [-]
		My favorite fact is that every single time an organization manages to make a functional development team that can repeatedly successfully navigate all the problems and deliver working software that adds real value, the high up decision makers always decide to scale the team next. Working teams are good for a project only, then they are destroyed.