[zokier]

That is just a sign that we are trying to run before we can walk. They key is in your own comment:

> At least with our current tools

We should be aiming more towards making projects with a scope that we can actually manage, instead of trying to build huge castles of sand and failing spectacularly. And of course continue to improve our tools to properly manage more complexity.

[nine_k]

I'm certain that brothers Wright did not have a rigorous mathematical model of their airplane. It is well known that Bell's telephone was invented by accident. I suspect we still lack a comprehensive theory of pizza-making.

Sometimes you just hit a mother lode, and keep digging, preferably doing proper geological research along the way. But to postpone practical applications before a complete theory is ready is to lack business sense.

[zokier]

But we are not in Wright era of computing. We are in the 737 era, or should be. But somehow our methods are not tracking that. Experimentation has its place, but it should be followed by rigor which we are very much missing.

[nine_k]

I'm afraid we are still not even in the brothers Wright era of project planning, though. At least, im many areas. In some areas we (humans) have considerable successes, like building oil rigs in the ocean. I suspect we lack a good understanding of software requirements. From it, to my mind, inadequate management practices follow.

[Jtsummers]

I've written something like this before, but I'll say it again:

The difficulty in software is its detachment from physics (when compared to other disciplines categorized as engineering). There are few physical couplings you can make with your transmission system or steering wheel. But with software, your couplings are essentially unbounded. This permits radically unsafe and unmaintainable software, where an equivalent physical system likely wouldn't even move. The nearest, in physical engineering, is electrical systems. But even then you still have to drive power through a constrained system and either can't power everything or set something on fire.

This forces a practical limit on how you design physical systems. A kind of simplicity often falls out as a consequence. But in software, complexity still reigns supreme because it can. Without a deliberate effort, it is easy to develop a complex system that is hard to maintain, hard to verify, hard to validate, and hard to extend.

[majormajor]

> We should be aiming more towards making projects with a scope that we can actually manage, instead of trying to build huge castles of sand and failing spectacularly. And of course continue to improve our tools to properly manage more complexity.

Its rarely the developer who decides the size, scope, and complexity of the project.

Reliability/extensibility/dev speed/complexity all trade off against each other, but if you're working for someone else, you have to present those tradeoffs to the right stakeholders, not just always choose simpler.

There's also the "knowing the future" problem - the right design for today might run into a wall when the assumptions or business goals change tomorrow.

[Dudeman112]

I don't think my org's gonna want to keep me in their payroll if I propose that to them