Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>With growing size or sophistication of the program, the operational argument quickly becomes impossible to carry through, and the general adherence to operational reasoning has to be considered one of the main causes of the persistence of the software crisis.

What "software crisis"? Since its inception in the 50s or so, software has only gone from strength to strength.




Projects running over-budget

Projects running over-time

Software was very inefficient

Software was of low quality

Software often did not meet requirements

Projects were unmanageable and code difficult to maintain

Software was never delivered

Yeah, that one.


A "crisis" would imply that:

1) we don't get increasingly bigger and more powerful systems

2) we're behind some previously existing "no crisis" state

Both (1) and (2) are factually wrong.

Projects running over-budge, over-time, often not meet requirements etc, are not a crisis in the actual meaning of the world.

It's just a normal state of affairs.

And despite that we have got from the laughingly primitive software in the 50s and 60s, to the software "eating the world" today, and have systems with 10 to 100 or 1000 more lines of code, and way more functionality -- even in our pockets.

If only "crisis" looked that way in other domains too.

It's not a crisis, it's just unrealistic expectations.

Even if we could do 100x better in the _future_, it wouldn't justify the term crisis for the state we're in, and have been for decades.


> Both (1) and (2) are factually wrong.

You are factually wrong because you know only the status quo that emerged from that crisis.

> Projects running over-budge, over-time, often not meet requirements etc, are not a crisis in the actual meaning of the world.

> It's just a normal state of affairs.

To you it is.

To the people in the 1960s, it wasn't.

Because they had previously experienced a state where the hardware imposed such drastical limits on the possible size and complexity of software that each programmer working on a project could intimately know and understand every piece of code in it and the requirements that influenced it.

The change from that to one where programmers understand only part of a project is absolutely fundamental and completely changes the way you have to work to achieve your goals. Now your project will fail if you cannot manage and divide-and-conquer its complexity in some way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: