6 ms·

Our industry is hugely based on illusions and misconceptions. There are only few places on earth where people regularly rebuild the skyscrapers to build taller

Our industry is hugely based on illusions and misconceptions. There are only few places on earth where people regularly rebuild the skyscrapers to build taller ones. The IT industry simply forces you to re-learn the same old paradigms in a new package just to gain 0.1% of something we cannot even define as an improvement.

pjmlp 9y ago
Quite common in fashion driven industries.
jwdunne 9y ago
One thing I've been looking at lately is the various strands of engineering (civil, electrical, mechanical). I've been looking for common threads and general principles that apply to software engineering that otherwise haven't been. A part of what inspired that search is what you discuss: a huge amount of rework. Tools that shift like sand dunes. Many principles and best practice based on "this is what worked for us". I can't seem to shake the feeling there must be a better way.
- dasil003 9y ago
  The fundamental difficulty is the blue sky nature of software. You can literally code anything you can imagine. Language semantics, algorithms, architecture, it's all up for grabs, it's all cheap, and the applications are unlimited. Compare with traditional engineering disciplines where you have massively constrained costs, materials, and even goals. What would civil engineering be like if instead of the immutable laws of physics you had a system designed from the tiniest quark up to the largest galaxy by humans, and if that design was subject to change on a whim?
- cyphar 9y ago
  I think that attempts to unify traditional forms of engineering with software engineering are doomed to failure, because they're so different as vocations. For example, the design and construction stages are indistinguishable (any sufficiently detailed design of software is effectively an implementation of the design). Normal engineering is not the same, and is likely one of the reasons that software prototyping often become the final product (which is definitely not true for traditional engineering). Fields like electrical engineering that use software engineering quite heavily are only similar to traditional engineering because of the traditional components of the other engineering discipline (electrical engineering requires circuit-board design that is distinct from fabrication, and prototypes are rarely promoted directly to the final product).
  - jwdunne 9y ago
    That's true. I don't think that there are major things in those disciplines that are directly applicable in a timeless fashion. My main goal is to find out how these disciplines came about. How exactly did they settle upon their body of knowledge such that they can produce reliable results in the way they do. Not so much what those methods are, but rather how they came about. What is the common thread there and how, if at all possible, can we use that accelerate the same maturity in software? Maybe it's a process that has to run its course? Maybe at 80 years old, if I live that long, I'll look on a very different kind of software development. With that said, I also have Fred Brooks whispering "no silver bullet" into my ear on the other shoulder.
- adrianN 9y ago
  Maybe the other engineers would love to be able to do more rework, but since they deal with hardware, changing things is a lot more expensive. Why do you think that their ways are superior? Construction projects too run way over budget and sometimes even fail, just like software.
  - jwdunne 9y ago
    You make a good point. Maybe their ways aren't superior - I didn't consider this. In that case, perhaps the issue isn't because we need to be more like other engineering disciplines but less like. I'm feeling for answers. I'm not saying I know what we need. I am, like I think everyone else is, still in the observation stage looking for hypotheses. I did find evidence based software engineering. This offered some interesting papers. I recommend this. There isn't much and it's far away from a cohesive theory but hopefully we can get there, as a field, soon. If someone is further along, or has some ideas, I'd love to speak with them.
eeZah7Ux 9y ago
This is what I most dislike about Go: it's a modest improvement. It could have been much better, with a higher-level and less verbose syntax and allow metaprogramming (e.g. like Nim).
wyager 9y ago
Architecture is thousands of years old. Programming as we know it is maybe 60. We're still figuring out how to do things correctly. Maybe we just figured out how to build a log cabin, but now some people are going back to mud huts because they're simpler.

pjmlp 9y ago

Quite common in fashion driven industries.

jwdunne 9y ago

One thing I've been looking at lately is the various strands of engineering (civil, electrical, mechanical). I've been looking for common threads and general principles that apply to software engineering that otherwise haven't been. A part of what inspired that search is what you discuss: a huge amount of rework. Tools that shift like sand dunes. Many principles and best practice based on "this is what worked for us". I can't seem to shake the feeling there must be a better way.

dasil003 9y ago
The fundamental difficulty is the blue sky nature of software. You can literally code anything you can imagine. Language semantics, algorithms, architecture, it's all up for grabs, it's all cheap, and the applications are unlimited. Compare with traditional engineering disciplines where you have massively constrained costs, materials, and even goals. What would civil engineering be like if instead of the immutable laws of physics you had a system designed from the tiniest quark up to the largest galaxy by humans, and if that design was subject to change on a whim?
cyphar 9y ago
I think that attempts to unify traditional forms of engineering with software engineering are doomed to failure, because they're so different as vocations. For example, the design and construction stages are indistinguishable (any sufficiently detailed design of software is effectively an implementation of the design). Normal engineering is not the same, and is likely one of the reasons that software prototyping often become the final product (which is definitely not true for traditional engineering). Fields like electrical engineering that use software engineering quite heavily are only similar to traditional engineering because of the traditional components of the other engineering discipline (electrical engineering requires circuit-board design that is distinct from fabrication, and prototypes are rarely promoted directly to the final product).
- jwdunne 9y ago
  That's true. I don't think that there are major things in those disciplines that are directly applicable in a timeless fashion. My main goal is to find out how these disciplines came about. How exactly did they settle upon their body of knowledge such that they can produce reliable results in the way they do. Not so much what those methods are, but rather how they came about. What is the common thread there and how, if at all possible, can we use that accelerate the same maturity in software? Maybe it's a process that has to run its course? Maybe at 80 years old, if I live that long, I'll look on a very different kind of software development. With that said, I also have Fred Brooks whispering "no silver bullet" into my ear on the other shoulder.
adrianN 9y ago
Maybe the other engineers would love to be able to do more rework, but since they deal with hardware, changing things is a lot more expensive. Why do you think that their ways are superior? Construction projects too run way over budget and sometimes even fail, just like software.
- jwdunne 9y ago
  You make a good point. Maybe their ways aren't superior - I didn't consider this. In that case, perhaps the issue isn't because we need to be more like other engineering disciplines but less like. I'm feeling for answers. I'm not saying I know what we need. I am, like I think everyone else is, still in the observation stage looking for hypotheses. I did find evidence based software engineering. This offered some interesting papers. I recommend this. There isn't much and it's far away from a cohesive theory but hopefully we can get there, as a field, soon. If someone is further along, or has some ideas, I'd love to speak with them.

eeZah7Ux 9y ago

This is what I most dislike about Go: it's a modest improvement. It could have been much better, with a higher-level and less verbose syntax and allow metaprogramming (e.g. like Nim).

wyager 9y ago

Architecture is thousands of years old. Programming as we know it is maybe 60. We're still figuring out how to do things correctly. Maybe we just figured out how to build a log cabin, but now some people are going back to mud huts because they're simpler.