8 ms·

Software is up there as the most complex thing ever created. People have been putting up houses for thousands of years, And modern big bridges for hundreds. Bi

Software is up there as the most complex thing ever created. People have been putting up houses for thousands of years, And modern big bridges for hundreds. Big software is ~40-60 years old. Its hard to have rules of thumb and best practice that will deliver the 'on time outcome'. Give it another 100 years. Most dev work right now is still just attempting to deliver correct software. let alone on time or on budget.

dredmorbius 8y ago
The Linux kernel is several times more complex than the Space shuttle. Order of magnitude as I recall.
- CamTin 8y ago
  Much harder to step the shuttle through a debugger though.
  - dredmorbius 8y ago
    Also, generally, much less need. The Shuttle is a physical system, and can be directly observed and components either individually (unit) or collectively (integration) tested. "Debuggers" are the monitoring, telemetry, sensing, and forensics equipment, data, and processes applied to each test, launch, and component. We have debuggers because code is otherwise a black box. Debuggers are a visualisation technology.
markkanof 8y ago
In addition, as requirements get more complex and users expect more polished products, we end up relying on more and more open source/reusable infrastructure and libraries. Those tools allow us to not reinvent the wheel and accomplish more in the same amount of time, but they also add to the complexity of any software system. House building has become somewhat more complicated over the years as building codes are made stricter and new techniques are developed, but for the most part it is just a switch to a new way of doing things vs. in the software world where we will continue to pile on more and more levels of abstraction, but can't reasonably expect to have at least some kind of understanding of the underlying layers.
rurban 8y ago
Nonsense. Software is not more complex as other engineering jobs. It is much less complex than e.g. architecture, which is a generalization over multiple technical jobs. In general you cannot trust a young architect with less than 20 years of experience. You can appreciate the end quality because of the ambition, but with the time and budget you need to be careful. But other typical engineering jobs also, which are not as simple and logical as software. I worked professionally in a couple of high-tech engineering jobs, as architect, surveyor, city planner, civil engineering, construction, stage design, movies, automotive engineering (F1), games and at internet service providers. (but no airplanes, nuclear power plants or rockets, sorry. Lots of hospitals still.) The SW development jobs compared to that were always the easiest, most creative, most rewarding, and best paid also. The problem with SW planning is pure lack of experience and poor engineering practices. A good SW engineer can hold his estimates, just as an experienced architect can hold his date and costs. In practice it rarely happens, I only know a couple of successful projects with smaller companies, but the good and big companies mostly deliver on time and budget. As you mentioned houses and bridges. With houses you don't change engineering paradigms every 5 years as it might fancy you. You never try out new materials which are not tested over 10 years at least. These things need to stay up for 50 years at least. With bridges you cannot really plan them properly. Well, you can. But a typical bridge engineer multiplies the safety factor with 10, leading up to 10x more material as needed, as you can hardly estimate the dynamic peaks and resonance frequencies. With highly dynamic forces such as e.g. in a F1 gearbox, a huge spring with max 4000 Nm forces on your shafts. There you cannot apply any 10x rule. This thing needs to be perfect. You plan to avoid the peaks at all, avoiding the dangerous frequencies. Comparable to wind forces on a bridge. But in practice you look at best practices. You build dynamic physical models and simulations. And measure. And apply safety margins. E.g. with the big steel bridge next to my home, the famous "Blaues Wunder"in Dresden, the general public and politicians never trusted their engineers with this fancy new steel design, so it had to made 10x bigger and heavier, and even on opening day they invited the whole town to test it live, with lots of heavy trucks, a tramway and pedestrians walking over the bridge and jumping on it all at once. It stills stands today, but could have been made much simpler and elegant by todays knowledge. Now compare that to modern SW engineering. You got a fancy new framework and language, looking for engineers with at least 10 years experience in that, with the framework existing for 2 years. You got massively overhyped tools which rarely deliver on their hype, complete lack of security, memory safety, type safety or concurrency safety, completely outdated API's like blocking IO or POSIX or threads, and undesigned monsters like C or C++. Good luck with that. That's of course a death march. Still with proper tools and proper management it's much easier than everything else. In automotive everything was properly planned, with traditional waterfall. Everything worked as planned. Even if it was hugely complex, much more complex than a simple OS. In my own SW I never miss my milestones or overdo my budget. In architecture we always did. With huge costs up into billions. Only once we went under costs by 200 millions with the biggest building construction project in Austria. This was a miracle then.

dredmorbius 8y ago

The Linux kernel is several times more complex than the Space shuttle. Order of magnitude as I recall.

CamTin 8y ago
Much harder to step the shuttle through a debugger though.
- dredmorbius 8y ago
  Also, generally, much less need. The Shuttle is a physical system, and can be directly observed and components either individually (unit) or collectively (integration) tested. "Debuggers" are the monitoring, telemetry, sensing, and forensics equipment, data, and processes applied to each test, launch, and component. We have debuggers because code is otherwise a black box. Debuggers are a visualisation technology.

markkanof 8y ago

In addition, as requirements get more complex and users expect more polished products, we end up relying on more and more open source/reusable infrastructure and libraries. Those tools allow us to not reinvent the wheel and accomplish more in the same amount of time, but they also add to the complexity of any software system. House building has become somewhat more complicated over the years as building codes are made stricter and new techniques are developed, but for the most part it is just a switch to a new way of doing things vs. in the software world where we will continue to pile on more and more levels of abstraction, but can't reasonably expect to have at least some kind of understanding of the underlying layers.

rurban 8y ago

Nonsense. Software is not more complex as other engineering jobs. It is much less complex than e.g. architecture, which is a generalization over multiple technical jobs. In general you cannot trust a young architect with less than 20 years of experience. You can appreciate the end quality because of the ambition, but with the time and budget you need to be careful. But other typical engineering jobs also, which are not as simple and logical as software. I worked professionally in a couple of high-tech engineering jobs, as architect, surveyor, city planner, civil engineering, construction, stage design, movies, automotive engineering (F1), games and at internet service providers. (but no airplanes, nuclear power plants or rockets, sorry. Lots of hospitals still.) The SW development jobs compared to that were always the easiest, most creative, most rewarding, and best paid also. The problem with SW planning is pure lack of experience and poor engineering practices. A good SW engineer can hold his estimates, just as an experienced architect can hold his date and costs. In practice it rarely happens, I only know a couple of successful projects with smaller companies, but the good and big companies mostly deliver on time and budget. As you mentioned houses and bridges. With houses you don't change engineering paradigms every 5 years as it might fancy you. You never try out new materials which are not tested over 10 years at least. These things need to stay up for 50 years at least. With bridges you cannot really plan them properly. Well, you can. But a typical bridge engineer multiplies the safety factor with 10, leading up to 10x more material as needed, as you can hardly estimate the dynamic peaks and resonance frequencies. With highly dynamic forces such as e.g. in a F1 gearbox, a huge spring with max 4000 Nm forces on your shafts. There you cannot apply any 10x rule. This thing needs to be perfect. You plan to avoid the peaks at all, avoiding the dangerous frequencies. Comparable to wind forces on a bridge. But in practice you look at best practices. You build dynamic physical models and simulations. And measure. And apply safety margins. E.g. with the big steel bridge next to my home, the famous "Blaues Wunder"in Dresden, the general public and politicians never trusted their engineers with this fancy new steel design, so it had to made 10x bigger and heavier, and even on opening day they invited the whole town to test it live, with lots of heavy trucks, a tramway and pedestrians walking over the bridge and jumping on it all at once. It stills stands today, but could have been made much simpler and elegant by todays knowledge. Now compare that to modern SW engineering. You got a fancy new framework and language, looking for engineers with at least 10 years experience in that, with the framework existing for 2 years. You got massively overhyped tools which rarely deliver on their hype, complete lack of security, memory safety, type safety or concurrency safety, completely outdated API's like blocking IO or POSIX or threads, and undesigned monsters like C or C++. Good luck with that. That's of course a death march. Still with proper tools and proper management it's much easier than everything else. In automotive everything was properly planned, with traditional waterfall. Everything worked as planned. Even if it was hugely complex, much more complex than a simple OS. In my own SW I never miss my milestones or overdo my budget. In architecture we always did. With huge costs up into billions. Only once we went under costs by 200 millions with the biggest building construction project in Austria. This was a miracle then.