5 ms·

Civil (and other engineering) got better because there was motivation to improve that came from multiple directions: literal lives at stake, the pride of good c

by sidlls 5y ago

Civil (and other engineering) got better because there was motivation to improve that came from multiple directions: literal lives at stake, the pride of good craftsmanship, iterative or even grand steps forward in knowledge, etc. Software engineering as a discipline is dominated by appeals to authority ("Clean Code", "Google does it this way", "Djikstra said so", etc.) without any (or at least not much) attempt to ask why or whether. I think we'll automate away much of software engineering (likely with very poor, inefficient, and buggy implementations) before it matures enough as an industry to be actual engineering. Engineering (and the science behind it for that matter) advances from curiosity and a healthy skepticism, not the rampant ego-driven self-promotion that runs through SE.

julianlam 5y ago
I feel like I already spend 90% of my day gluing together various disparate APIs. Is this the logical conclusion to software development? I adore the craft-like parts of software dev, wouldn't trade it for anything.
pjmlp 5y ago
What about we apply this to software engineering? > If a builder constructs a house for a man but does not make it conform to specifications so that a wall then buckles, that builder shall make that wall sound using his own silver. - Code of Hammurabi, 1755–1750 BC
- zdkl 5y ago
  Define "specifications" and "conform" in terms that I might hear from a non technical client.
  - wheelinsupial 5y ago
    The engineer is responsible for taking non-technical language from the client and turning it into technical engineering specifications. Why does this fall to the client in software?
  - pjmlp 5y ago
    That is what contracts are for.
- PeterisP 5y ago
  The software is as sturdy as the day it was written, there has been no deterioration - if your copy has become broken, the builder can easily supply another copy using his own silver. On the other hand, if the customer finds out that their door is inconvenient and it would be much better to have it a bit to the right, noone expects a house builder to fix that at their expense, you bought what you saw. And the same thing if it turns out that the house is very difficult to maintain because it's inconvenient to get to the piping. And ifthe customer buys a bigger car and the garage needs to be adapted to fit it, that's their expense. Those three would be the main equivalents of all the commonly seen software "best practices" which generally either refer to feature design, the maintainability of the code, and ensuring compatibility when an integrated system changes.
  - pjmlp 5y ago
    Unfortunately only consulting and high integrity computing are the main areas where software companies get liability for delivering faulty products. One day that will extend to everyone like in all industries. Who can't manage then closes doors, just like bad restaurants after a surprise health check.
dtech 5y ago
This is a symptom of the lack of knowledge not a cause. Imagine you want to built a building but no one really knows how, then copying successfully completed buildings, and established construction engineers and companies is a pretty good idea. That's what's going on in SE.
- habitue 5y ago
  The difference is the feedback is pretty incontrovertible if you build a building and it falls down. If you use composition instead of inheritance, the evidence of whether you're right or wrong comes in the form of ... slightly faster refactoring two years later? Maybe? All of the stuff engineers argue about and that seem really subjective are the things where you just get very little feedback about who is right or wrong.
- sidlls 5y ago
  It's both, as it's a feedback cycle. This industry, like many others, rewards narcissism and loudmouths above all else. It does so in the large (e.g. Fowler or Uncle Bob worship; "ex-FAANG" cache) and in the small (the self-promoting engineer who touts his work even if it's not all that great gets promoted over the "soft-power" engineer managing tough projects lowkey). In this environment the symptom feeds the cause, because nobody stops to question whether the symptom is even a symptom. The root cause, ignorance, is entrenched and made deeper, which feeds the symptom. And so on.
  - the_only_law 5y ago
    I just want the fuck out, there no realistic alternative.

by sidlls 5y ago

julianlam 5y ago

I feel like I already spend 90% of my day gluing together various disparate APIs. Is this the logical conclusion to software development? I adore the craft-like parts of software dev, wouldn't trade it for anything.

pjmlp 5y ago

What about we apply this to software engineering? > If a builder constructs a house for a man but does not make it conform to specifications so that a wall then buckles, that builder shall make that wall sound using his own silver. - Code of Hammurabi, 1755–1750 BC

zdkl 5y ago
Define "specifications" and "conform" in terms that I might hear from a non technical client.
- wheelinsupial 5y ago
  The engineer is responsible for taking non-technical language from the client and turning it into technical engineering specifications. Why does this fall to the client in software?
- pjmlp 5y ago
  That is what contracts are for.
PeterisP 5y ago
The software is as sturdy as the day it was written, there has been no deterioration - if your copy has become broken, the builder can easily supply another copy using his own silver. On the other hand, if the customer finds out that their door is inconvenient and it would be much better to have it a bit to the right, noone expects a house builder to fix that at their expense, you bought what you saw. And the same thing if it turns out that the house is very difficult to maintain because it's inconvenient to get to the piping. And ifthe customer buys a bigger car and the garage needs to be adapted to fit it, that's their expense. Those three would be the main equivalents of all the commonly seen software "best practices" which generally either refer to feature design, the maintainability of the code, and ensuring compatibility when an integrated system changes.
- pjmlp 5y ago
  Unfortunately only consulting and high integrity computing are the main areas where software companies get liability for delivering faulty products. One day that will extend to everyone like in all industries. Who can't manage then closes doors, just like bad restaurants after a surprise health check.

dtech 5y ago

This is a symptom of the lack of knowledge not a cause. Imagine you want to built a building but no one really knows how, then copying successfully completed buildings, and established construction engineers and companies is a pretty good idea. That's what's going on in SE.

habitue 5y ago
The difference is the feedback is pretty incontrovertible if you build a building and it falls down. If you use composition instead of inheritance, the evidence of whether you're right or wrong comes in the form of ... slightly faster refactoring two years later? Maybe? All of the stuff engineers argue about and that seem really subjective are the things where you just get very little feedback about who is right or wrong.
sidlls 5y ago
It's both, as it's a feedback cycle. This industry, like many others, rewards narcissism and loudmouths above all else. It does so in the large (e.g. Fowler or Uncle Bob worship; "ex-FAANG" cache) and in the small (the self-promoting engineer who touts his work even if it's not all that great gets promoted over the "soft-power" engineer managing tough projects lowkey). In this environment the symptom feeds the cause, because nobody stops to question whether the symptom is even a symptom. The root cause, ignorance, is entrenched and made deeper, which feeds the symptom. And so on.
- the_only_law 5y ago
  I just want the fuck out, there no realistic alternative.