5 ms·

I 100% agree. The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. I recent

by hliyan 2y ago

I 100% agree. The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. I recently had an experience where a repair crew was worried about the odd looking placement of a concrete beam in my house. I brought over the blueprints, and the technician found the schedule of beams and columns within seconds, pinpointed the beam and said, "Ah, that's why. We just need to <solution I won't go into>". Just then it struck me how we can't do this in software engineering, even when the project is basically a bog-standard business app: CRUD API backed by an RDBMS.

skydhash 2y ago
That’s because the few hard rules you have to comply with have workarounds and matters rarely. In house construction, you have to care about weight, material degradation, the code, etc… there’s no such limitation on software so you can get something to work even if it’s born out of a LSD trip. But we do have some common concepts. But they’re theoretical, so only the people that read the books knows the jargon.
- namaria 2y ago
  I mean why should we expect software to have hard rules? Flexibility is the point, no?
  - HeyLaughingBoy 2y ago
    No. Flexibility is a side effect. Sometimes it's a useful side effect, other times it bites you in the ass.
  - Ma8ee 2y ago
    The rules are what make it flexible. The rules let me understand what the heck is going on in the code you wrote so I can change it. Code that is faster to rewrite from scratch isn’t flexible.
watt 2y ago
don't stress about it so much: look how many variations of plugs and sockets are for this one quite simple thing: https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets
VonGallifrey 2y ago
> I brought over the blueprints, and the technician found the schedule of beams and columns within seconds Is that really an example of the standardization you want? It shows that the blueprint was done in a way that the technician expected it to be, but I am not sure that these blueprints are standardized in that way globally. Each country has its standards and language. If an architect from a different country did that blueprint, I would bet that it would be significantly different from the blueprint you have. Software Engineering doesn't have a problem with country borders, but different languages would require different standards and conventions. Unless you can convince everyone to use the same language (which would be a bad idea; CRUD apps and rocket systems have different trade-offs), I doubt there could be an industry-wide standard.
- lanstin 2y ago
  But I can't look at the design from my desk-mate and hope to understand it quickly. We wall love to invent as much as possible ourselves, and we lack a common design language for the spaces we are problem solving in. Personally I don't entirely think it's a problem of discipline of software engineering, but a reflection of the fact that the space of possible solutions is so high for software, and the [opportunity] cost of missing a great solution because it is too different from previous solutions is so high (difference between 120 seconds application start and 120 milliseconds application start, for instance).
wongarsu 2y ago
Construction and civil engineering have been unable to agree on global conventions and standards, and they have a multi-millenia head start over software engineering. The US may claim to follow the "International Building Code", but it's just called that because a couple of small countries on the Americas have adopted it. For all intents and purposes it's a national standard. Globally we can't even agree on a system of units and measurements, never mind anything more consequential than that.
- Ma8ee 2y ago
  I’d say that globally we have agreed on a system of units and measurements. It’s just the US and a handful of third world countries that don’t follow that system.
  - Vilian 2y ago
    Only USA, Myanmar and Libera are switching to metric
    - gadflyinyoureye 2y ago
      You don’t think of those other two having their shit together. — Archer international man of mystery.
dranudin 2y ago
That is largely due to a difference in complexity.I would say that the level of complexity of a blueprint of a house is on par with a 20-30 line python solution of a leet code easy excercise to a programmer. If the one reading the blue print is an engineer and the one reading the python code is a programmer. A crud app is more like the blue prints for a vacuum cleaner or something like that.
HeyLaughingBoy 2y ago
I don't know that we'll ever be able to agree on "global standards" though. Software is too specialized for that. The only software standard that I'm reasonably familiar with is https://en.wikipedia.org/wiki/IEC_62304 https://en.wikipedia.org/wiki/IEC_62304 which is specific to Medical Devices. In a 62304-compliant project, we might be able to do something like your example, but it could take a while. OTOH, I'm told that my Aviation counterparts following DO-178 would almost certainly be able to do something comparable. It is going to be very industry dependent, where "industry" means aviation, or maritime, or railroad, or Healthcare, etc... Just "software" is too general to be meaningful these days.
- kmoser 2y ago
  The very point of ISO is to define international standards, many of which are used in software engineering.
  - HeyLaughingBoy 2y ago
    Yes, of course. My point is that those standards apply only to specific domains where software is applied, not to the software development industry as a whole.
TeMPOraL 2y ago
> The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. It can't, and it won't, as long as we insist on always working directly on the "single source of truth", and representing it as plaintext code. It's just not sufficient to comprehensibly represent all concerns its consumers have at the same time. We're stuck in endless fights about what is cleaner or more readable or more maintainable way of abstracting / passing errors / sizing functions / naming variables... and so on, because the industry still misses the actual answer: it depends on what you're doing at the moment. There is no one best representation, one best function size. In fact, one form may be ideal for you now, and the opposite of it may be ideal for you five minutes later, as you switch from e.g. understanding the module to debugging a specific issue in it. We've saturated the expressive capability of our programming paradigm. We're sliding back and forth along the Pareto frontier, like a drunkard leaning against a wall, trying to find their way back to a pub without falling over. No, inventing even more mathematically complex category of magic monads won't help, that's just repackaging complexity to reach a different point on the Pareto frontier. Hint: in construction, there is never one blueprint everyone works with. Try to fit all information about geometry, structural properties, material properties, interior arrangement, plumbing, electricity, insulation, HVAC, geological conditions, hydrological conditions, and tax conditions onto a single flat image, and... you'll get a good approximation of what source code looks like in programming as it is today.
- deleted 2y ago
  [deleted]
- gbro3n 2y ago
  I think we have to think of software like books and writing. It is about conveying information, and while there are grammatical rules to language and conventions around good and bad writing, we're generally happy to leave it there because too many rules is so constructive as to remove the ability to express information in the way we feel we need to. We just have to accept that some are better writers than others, or we like the style of some authors better.
  - 2y ago
buescher 2y ago
It's telling I think that the discussion becomes about standards, which software people like, rather than say, clear communication to technical stakeholders beyond the original programmer. I have a list somewhere I made of everyone that might eventually need to read an electronics schematic. Particularly to emphasize clarity to younger engineers and (ex-)hobbyists that think schematics are a kind of awkward source code or data entry for layout. It's not short: test, legal, quality control, manufacturing, firmware, sustaining/maintenance, sometimes even purchasing, etc. Whoever drew your blueprints knew they would be needed beyond getting the house up. What would the equivalent perspective and effort for software engineering be?

by hliyan 2y ago

skydhash 2y ago

That’s because the few hard rules you have to comply with have workarounds and matters rarely. In house construction, you have to care about weight, material degradation, the code, etc… there’s no such limitation on software so you can get something to work even if it’s born out of a LSD trip. But we do have some common concepts. But they’re theoretical, so only the people that read the books knows the jargon.

namaria 2y ago
I mean why should we expect software to have hard rules? Flexibility is the point, no?
- HeyLaughingBoy 2y ago
  No. Flexibility is a side effect. Sometimes it's a useful side effect, other times it bites you in the ass.
- Ma8ee 2y ago
  The rules are what make it flexible. The rules let me understand what the heck is going on in the code you wrote so I can change it. Code that is faster to rewrite from scratch isn’t flexible.

watt 2y ago

don't stress about it so much: look how many variations of plugs and sockets are for this one quite simple thing: https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets

VonGallifrey 2y ago

> I brought over the blueprints, and the technician found the schedule of beams and columns within seconds Is that really an example of the standardization you want? It shows that the blueprint was done in a way that the technician expected it to be, but I am not sure that these blueprints are standardized in that way globally. Each country has its standards and language. If an architect from a different country did that blueprint, I would bet that it would be significantly different from the blueprint you have. Software Engineering doesn't have a problem with country borders, but different languages would require different standards and conventions. Unless you can convince everyone to use the same language (which would be a bad idea; CRUD apps and rocket systems have different trade-offs), I doubt there could be an industry-wide standard.

lanstin 2y ago
But I can't look at the design from my desk-mate and hope to understand it quickly. We wall love to invent as much as possible ourselves, and we lack a common design language for the spaces we are problem solving in. Personally I don't entirely think it's a problem of discipline of software engineering, but a reflection of the fact that the space of possible solutions is so high for software, and the [opportunity] cost of missing a great solution because it is too different from previous solutions is so high (difference between 120 seconds application start and 120 milliseconds application start, for instance).

wongarsu 2y ago

Construction and civil engineering have been unable to agree on global conventions and standards, and they have a multi-millenia head start over software engineering. The US may claim to follow the "International Building Code", but it's just called that because a couple of small countries on the Americas have adopted it. For all intents and purposes it's a national standard. Globally we can't even agree on a system of units and measurements, never mind anything more consequential than that.

Ma8ee 2y ago
I’d say that globally we have agreed on a system of units and measurements. It’s just the US and a handful of third world countries that don’t follow that system.
- Vilian 2y ago
  Only USA, Myanmar and Libera are switching to metric
  - gadflyinyoureye 2y ago
    You don’t think of those other two having their shit together. — Archer international man of mystery.

dranudin 2y ago

That is largely due to a difference in complexity.I would say that the level of complexity of a blueprint of a house is on par with a 20-30 line python solution of a leet code easy excercise to a programmer. If the one reading the blue print is an engineer and the one reading the python code is a programmer. A crud app is more like the blue prints for a vacuum cleaner or something like that.

HeyLaughingBoy 2y ago

I don't know that we'll ever be able to agree on "global standards" though. Software is too specialized for that. The only software standard that I'm reasonably familiar with is https://en.wikipedia.org/wiki/IEC_62304 https://en.wikipedia.org/wiki/IEC_62304 which is specific to Medical Devices. In a 62304-compliant project, we might be able to do something like your example, but it could take a while. OTOH, I'm told that my Aviation counterparts following DO-178 would almost certainly be able to do something comparable. It is going to be very industry dependent, where "industry" means aviation, or maritime, or railroad, or Healthcare, etc... Just "software" is too general to be meaningful these days.

kmoser 2y ago
The very point of ISO is to define international standards, many of which are used in software engineering.
- HeyLaughingBoy 2y ago
  Yes, of course. My point is that those standards apply only to specific domains where software is applied, not to the software development industry as a whole.

TeMPOraL 2y ago

> The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. It can't, and it won't, as long as we insist on always working directly on the "single source of truth", and representing it as plaintext code. It's just not sufficient to comprehensibly represent all concerns its consumers have at the same time. We're stuck in endless fights about what is cleaner or more readable or more maintainable way of abstracting / passing errors / sizing functions / naming variables... and so on, because the industry still misses the actual answer: it depends on what you're doing at the moment. There is no one best representation, one best function size. In fact, one form may be ideal for you now, and the opposite of it may be ideal for you five minutes later, as you switch from e.g. understanding the module to debugging a specific issue in it. We've saturated the expressive capability of our programming paradigm. We're sliding back and forth along the Pareto frontier, like a drunkard leaning against a wall, trying to find their way back to a pub without falling over. No, inventing even more mathematically complex category of magic monads won't help, that's just repackaging complexity to reach a different point on the Pareto frontier. Hint: in construction, there is never one blueprint everyone works with. Try to fit all information about geometry, structural properties, material properties, interior arrangement, plumbing, electricity, insulation, HVAC, geological conditions, hydrological conditions, and tax conditions onto a single flat image, and... you'll get a good approximation of what source code looks like in programming as it is today.

deleted 2y ago
[deleted]
gbro3n 2y ago
I think we have to think of software like books and writing. It is about conveying information, and while there are grammatical rules to language and conventions around good and bad writing, we're generally happy to leave it there because too many rules is so constructive as to remove the ability to express information in the way we feel we need to. We just have to accept that some are better writers than others, or we like the style of some authors better.
- 2y ago

buescher 2y ago

It's telling I think that the discussion becomes about standards, which software people like, rather than say, clear communication to technical stakeholders beyond the original programmer. I have a list somewhere I made of everyone that might eventually need to read an electronics schematic. Particularly to emphasize clarity to younger engineers and (ex-)hobbyists that think schematics are a kind of awkward source code or data entry for layout. It's not short: test, legal, quality control, manufacturing, firmware, sustaining/maintenance, sometimes even purchasing, etc. Whoever drew your blueprints knew they would be needed beyond getting the house up. What would the equivalent perspective and effort for software engineering be?