5 ms·

We have absolutely no idea how to write code. I always wonder if it's like this for other branches of engineering too? I wonder if engineers who designed my ele

We have absolutely no idea how to write code. I always wonder if it's like this for other branches of engineering too? I wonder if engineers who designed my elevator or airplane had "ok it's very surprising that it's working, let's not touch this" moments. Or chemical engineers synthesize medicines in way nobody but a rockstar guru understands but everyone changes all the time. I wonder if my cellphone is made by machines designed in early 1990s because nobody was able to figure out what that one cog is doing. Software is a mess. I've seen some freakishly smart people capable of solving very hard problems writing code that literally changes the world at this very moment. But the code itself is, well, a castle of shit. Why? Is it because our tools (programming languages, compilers etc) are still stone age technology? Is it because software is inherently a harder problem than say machines or chemical processes for the human brain? Is it because software engineers are less educated than other engineers? .....?

abledon 8y ago
Your 2nd to last one is right I think. Other forms of engineering are constrained by physical world rules. In software we have to recreate reality and redefine and model how the real world system works. Mech eng/ chem eng etc don’t have to recreate reality , physics just works and will always work .
b_t_s 8y ago
I think it's because software is inherently easier and less critical...castles of shit actually work. Software is fairly unique in that level of quality and reliability needed to have significant economic benefit is very low, and the consequences of system failure are rarely severe. That's not the case in most branches of engineering. The complexity levels are also off the charts, in large part because economic value is so loosely coupled with quality. In many cases more turds are more profitable.
52-6F-62 8y ago
>I wonder if engineers who designed my elevator or airplane had "ok it's very surprising that it's working, let's not touch this" moments. I honestly sometimes do wonder. Judging by the elevators in my building some things even barely work at times. They go down often and require parts replacements that take weeks to arrive. They're barely 3 years old.
- krallja 8y ago
  > They go down often Isn’t that one of the two main features of the product?
  - gnulinux 8y ago
    "to go down" means "to be in a non-functional state" as in "Facebook went down". Compare to "to go up" like "servers are up" i.e. servers are functioning.
    - humbledrone 8y ago
      I think maybe you didn't get the joke
    - cuddlecake 8y ago
      This is the biggest whoosh I have ever witnessed.
enjoiful 8y ago
The difference is, an elevator is a precisely defined problem and never needs to have its functionality improved and changed. In fact, you could build the exact elevator almost identically. Software is never like that — it’s dynamic and constantly changing throughout the life cycle of the software.
- Invictus0 8y ago
  > an elevator is a precisely defined problem Ha! As a mechanical engineer, no, nothing in reality is ever precisely defined. Consider that every single part in the elevator has a tolerance: none of the parts are exactly the same in every elevator. Did you account for thermal expansion? What about wear? Fatigue? > Software is never like that — it’s dynamic and constantly changing throughout the life cycle of the software. But elevators need to be shipped right the first time and can't make mistakes; with software, it almost never works perfectly no matter how much time passes.
  - gnulinux 8y ago
    > with software, it almost never works perfectly no matter how much time passes. There is a person inside me -- whenever this is said -- that wants to shout "No! You can prove correctness of your program!". But this complicates the issue even more, since afaik no elevator's correctness is proven but it just works. Mechanical stuff somehow just magically work without proof whereas it's still debatable if proven software works (did we prove the software that proved it?). I don't know what's the difference. Maybe elevator has a well-defined structure, it goes up and down, opens the door etc, even though implementation can change (as you explained). But maybe software isn't like that. Idk.
    - solveit 8y ago
      Turns out physical reality is robust in ways code written by mere mortals can only dream of.
      - regularfry 8y ago
pier25 8y ago
The best code I've written is when rewriting some code from scratch having a clear picture of the solution, or when I solve the same problem a couple of times. Solving complex stuff takes a lot of effort, and usually most companies do not have the resources or the motivation to go back and rewrite a product.
sonnyblarney 8y ago
Brilliance is not indication of an ability to write clean code. In my experience, code needs to be re-factored 3 times before it starts to look coherent and clean. But 99% of projects can't justify that kind of expense. But good code is very feasible, just takes time.
- james_s_tayler 8y ago
  I'll expand this further by saying yes to all of the above with the addition that to get it perfect in my experience requires about 7 iterations.
  - sonnyblarney 8y ago
    Yup. Diminishing returns on that though. I'm happy with 3. Unless it's API or public code used by a wide audience then it needs a lot of eyes and has to be very clean.
twblalock 8y ago
It's because software that solves the problem the business intends to solve, and can be maintained without unreasonable time and effort, is good enough. Code readability and maintainability problems are not business problems unless they impact developer productivity to the extent that feature development becomes too slow to tolerate. After all, if work inside the codebase does not make a difference to the people who use the software, in terms of reliability or features, is it really worth doing? The trick is to find a balance where efforts to improve code quality actually improve outcomes for the business and the users -- otherwise it's not justifiable to take time away from feature development, which is what the users actually care about.
- rabidrat 8y ago
  not all software is solving a "business problem". sometimes it's academic, or hobby, or government. but always the code is shit.
booleandilemma 8y ago
We gotta finish these bridge foundations by this Friday, guys. The sprint ends next week and it’s a short week with Thanksgiving coming up.
pavlov 8y ago
It's like that in other fields of engineering too, when they are making something they haven't built before. That's the essential part: for example, a lot of construction is really just rebuilding the same thing that's already been built 100,000 times in the past 100 years. When they attempt to build something new, it often ends up like software – tremendous overruns in both cost and schedule. C.f. the only new nuclear power plant being built in the West, which is $4 billion over budget and ten years late: https://en.wikipedia.org/wiki/Olkiluoto_Nuclear_Power_Plant#Unit_3 https://en.wikipedia.org/wiki/Olkiluoto_Nuclear_Power_Plant#... The reason why this feels more commonplace in software is that we're usually designing something new. Software has essentially no reproduction costs, so there's no reason for anybody to design software that's a carbon copy of something you can already download or buy off-the-shelf. That's not the case in engineering of physical products or works. New buildings are needed all the time, even if they're performing exactly the same function as the building in the adjacent lot.
- augustl 8y ago
  > It's like that in other fields of engineering too, when they are making something they haven't built before. Exactly this. I like to use an analogy of building bridges :) - OK, we have this valley and we want to drive cars over it. What do we do? - Hmm, we could just make the road along the bottom of the valley - Wouldn't that cause the cars to fall because of the steep angle? - Good point. Maybe if we built the road with a lot of twist and turns - Then it's a slow and long drive. - Maybe we could build some sort of catapult setup to throw the cars across the valley - That would make safety a concern though. Is there a way we could use helicopter rotors to suspend a road in mid air over the valley? - Or what if we attach the road to each side of the valley and make a road that's strong enough to not crack in the middle under its own weight? - Yeah, that sounds like a good idea. How do we make sure it can hold its own weight, though? - .....etc
  - exikyut 8y ago
    Very interesting point. I must admit that when I saw valley in > OK, we have this valley I immediately thought about SV, and then as I read > - Maybe we could build some sort of catapult setup to throw the cars > * across the valley* I imagined some kind of scenario happening in an alternate reality where a startup was trying to dream up a viable way to actually achieve this in SV. It was funny because of the fact that a lot of the ideas people do come up with are probably ideologically very similar in magnitude and ridiculous impossibility.
z3t4 8y ago
The larger a code base grows, the worse it will get. Once in a while you get a problem that can only be solved by a "hack". And once in a while you need to make performance optimizations. Then time goes by, things are forgotten, the language changes, the OS get replaced, the machine gets replaced, etc.
mbrock 8y ago
I think a lot of programming could be described as "formalizing the logic of a business" which is a very strange and interesting problem. Programming also involves things like "formalizing and automating the representation of knowledge in general" which is a holy grail of philosophy since Leibniz's time. We're always building on top of preexisting ontologies and logics which sometimes fail to even make sense, or which make it tedious to express things that we would want to consider elementary (Unix, TCP, Java, GTK+, SQL, etc). And we're always vulnerable to being smacked on the head by yet another "Falsehoods Programmers Believe About X" post detailing the myriad ways in which we routinely falsify and oversimplify to deal with the boundless complexity of actual reality and the horrendous details of legacy bureaucracy.
croo 8y ago
There is one fundamental difference between software engineering and any other type of engineering. It's that the feedback of the rules that govern the outcome is instant and received by multiple human senses. If you hit something with a hammer the result and response is instant. You can feel the nail went deeper before you look, you can hear you hit the head correctly before you think about it. You can feel the vibration and hear and feel and see the wood crack before you could read a sentence about it. You don't have to compile the hammer and run the hit and read the result from the screen and if you logged the right things you will see something about the result based on what you logged but not quite everything because that would be an unintelligible mess. If you compiled the right version of hammer that is. You don't even know for sure if you are holding a hammer. Of course that's not called a hammer but a unique tool you downloaded because they said it is the new best tool of the year - and there are several famous new tools every year. Though you cannot be sure if that tool helps in your job until you try to use it as you don't know if you are using a hammer or an excavation machine and both can be suitable for the task one being slightly bigger though.
eV6ahne6bei 8y ago
> I always wonder if it's like this for other branches of engineering too? EE here. It's not. The entry bar is much higher: most of the time difficult projects are given to senior engineers. It takes a degree and many years of work to get there. > Or chemical engineers synthesize medicines in way nobody but a rockstar guru understands Been there. Not at all. > cellphone is made by machines designed in early 1990s because nobody was able to figure out what that one cog is doing Same. Part of the reason is that any physical component adds cost, weight, and so on to a project. In software you can throw code and random libraries at a problem and nobody will notice until vulnerabilities start to pop later on.
jonathanstrange 8y ago
Not exactly relevant to the overall discussion but I've been dreaming for a long time about programming an elevator such that it arrives faster and skips other floors if a user frantically pushes the call button repeatedly. Same for traffic lights with push buttons. Maybe it's a good thing that I'm not an engineer.
- exikyut 8y ago
  There are apocryphal stories about elevators that let you push/hold buttons to cancel floor selections (eg, https://www.youtube.com/watch?v=eQSdKe5kArA https://www.youtube.com/watch?v=eQSdKe5kArA) or skip floors. I often forget to try them, but on the few occasions I've remembered nothing has happened. All elevators accept a standardized fire/security key that enables "exclusive" mode that lets you tell the lift "go to this floor" and it will do so: https://www.youtube.com/watch?v=1Uh_N1O3E4E https://www.youtube.com/watch?v=1Uh_N1O3E4E (a reasonable sink of 1hr) As for traffic lights I'm aware (at least in Australia) that they all tie back to a realtime system that lets a control room instruct lights to turn green and so forth. (Presumably the immediate action is that the lights that are currently green immediately turn orange, then red after the normal delay.) You can get summarily fired for misusing this though. I've also heard (IIRC on a TV documentary-type show) that ambulances tie into this system with live GPS tracking such that lights turn green as they approach, but this is sufficiently fantastic that I'm waiting to trust-but-verify it before I quote it with confidence. Under normal use some traffic lights are traffic based while others have timers. The ones that are traffic based will take into consideration whether the pedestrian crossing button has been pushed and reduce the threshold value needed for the actual traffic lights to turn red. The other timer ones - like the really annoying ones outside my local mall :) - are on a fixed timer, and I try to run for that one when I know it's about to turn green, or just accept and twiddle my fingers while I wait if I miss it. It'd be nice if elevator simulators were satisfying to write. Although, actually... I've just realized that with Unity you could have _quite_ a lot of fun :D... (hmm, I've had GPU on my wishlist for about 15 years now, now I really want one)
packetpirate 8y ago
One reason is that there's still a divide in understanding of the requirements to actually solve a problem between management and the engineering team. Unrealistic deadlines are given, and as a result, shit is produced.
yarg 8y ago
I don't think it's any of the reasons that you listed. To a large extent, I blame management - they push sub-optimal solutions because it's generally the fastest way to resolve the immediate problem. This generally results in poor solutions being piled up on top of each other that becomes progressively more impossible to maintain. This despite the fact that if additional time were allocated to come up with a better solution, tomorrow's software would be easier to integrate on top of today's, and with a higher quality of code. But the reason that managers behave like this is because they can - and this I think has more to do with the ethereal and timeless nature of software than anything else. In the real world it simply is not possible to put together a physical artifact with the sort of compromised constructs that appears in software. There are costs of material to consider; costs of production. There's degradation over time. All of these aspects of physical constructs provide a strong motivation to produce a quality product - not out of beneficence, but because (quality engineers aside) it's cheaper and it's really the only feasible option.
forgottenpass 8y ago
We have plenty of ideas on how to write code well. The catch is that they all make development slower and more expensive (at least up front, maybe the technical debt will come back to bite, maybe not).
timdellinger 8y ago
Chemical synthesis of medicine is highly scrutinized and fairly well understood, but there are a lot of other products that large chemical companies make in great quantity that are basically made using Black Magic. Tinker with it until it works, then don't mess with it!

abledon 8y ago

Your 2nd to last one is right I think. Other forms of engineering are constrained by physical world rules. In software we have to recreate reality and redefine and model how the real world system works. Mech eng/ chem eng etc don’t have to recreate reality , physics just works and will always work .

b_t_s 8y ago

I think it's because software is inherently easier and less critical...castles of shit actually work. Software is fairly unique in that level of quality and reliability needed to have significant economic benefit is very low, and the consequences of system failure are rarely severe. That's not the case in most branches of engineering. The complexity levels are also off the charts, in large part because economic value is so loosely coupled with quality. In many cases more turds are more profitable.

52-6F-62 8y ago

>I wonder if engineers who designed my elevator or airplane had "ok it's very surprising that it's working, let's not touch this" moments. I honestly sometimes do wonder. Judging by the elevators in my building some things even barely work at times. They go down often and require parts replacements that take weeks to arrive. They're barely 3 years old.

krallja 8y ago
> They go down often Isn’t that one of the two main features of the product?
- gnulinux 8y ago
  "to go down" means "to be in a non-functional state" as in "Facebook went down". Compare to "to go up" like "servers are up" i.e. servers are functioning.
  - humbledrone 8y ago
    I think maybe you didn't get the joke
  - cuddlecake 8y ago
    This is the biggest whoosh I have ever witnessed.

enjoiful 8y ago

The difference is, an elevator is a precisely defined problem and never needs to have its functionality improved and changed. In fact, you could build the exact elevator almost identically. Software is never like that — it’s dynamic and constantly changing throughout the life cycle of the software.

Invictus0 8y ago
> an elevator is a precisely defined problem Ha! As a mechanical engineer, no, nothing in reality is ever precisely defined. Consider that every single part in the elevator has a tolerance: none of the parts are exactly the same in every elevator. Did you account for thermal expansion? What about wear? Fatigue? > Software is never like that — it’s dynamic and constantly changing throughout the life cycle of the software. But elevators need to be shipped right the first time and can't make mistakes; with software, it almost never works perfectly no matter how much time passes.
- gnulinux 8y ago
  > with software, it almost never works perfectly no matter how much time passes. There is a person inside me -- whenever this is said -- that wants to shout "No! You can prove correctness of your program!". But this complicates the issue even more, since afaik no elevator's correctness is proven but it just works. Mechanical stuff somehow just magically work without proof whereas it's still debatable if proven software works (did we prove the software that proved it?). I don't know what's the difference. Maybe elevator has a well-defined structure, it goes up and down, opens the door etc, even though implementation can change (as you explained). But maybe software isn't like that. Idk.
  - solveit 8y ago
    Turns out physical reality is robust in ways code written by mere mortals can only dream of.
    - regularfry 8y ago

pier25 8y ago

The best code I've written is when rewriting some code from scratch having a clear picture of the solution, or when I solve the same problem a couple of times. Solving complex stuff takes a lot of effort, and usually most companies do not have the resources or the motivation to go back and rewrite a product.

sonnyblarney 8y ago

Brilliance is not indication of an ability to write clean code. In my experience, code needs to be re-factored 3 times before it starts to look coherent and clean. But 99% of projects can't justify that kind of expense. But good code is very feasible, just takes time.

james_s_tayler 8y ago
I'll expand this further by saying yes to all of the above with the addition that to get it perfect in my experience requires about 7 iterations.
- sonnyblarney 8y ago
  Yup. Diminishing returns on that though. I'm happy with 3. Unless it's API or public code used by a wide audience then it needs a lot of eyes and has to be very clean.

twblalock 8y ago

It's because software that solves the problem the business intends to solve, and can be maintained without unreasonable time and effort, is good enough. Code readability and maintainability problems are not business problems unless they impact developer productivity to the extent that feature development becomes too slow to tolerate. After all, if work inside the codebase does not make a difference to the people who use the software, in terms of reliability or features, is it really worth doing? The trick is to find a balance where efforts to improve code quality actually improve outcomes for the business and the users -- otherwise it's not justifiable to take time away from feature development, which is what the users actually care about.

rabidrat 8y ago
not all software is solving a "business problem". sometimes it's academic, or hobby, or government. but always the code is shit.

booleandilemma 8y ago

We gotta finish these bridge foundations by this Friday, guys. The sprint ends next week and it’s a short week with Thanksgiving coming up.

pavlov 8y ago

It's like that in other fields of engineering too, when they are making something they haven't built before. That's the essential part: for example, a lot of construction is really just rebuilding the same thing that's already been built 100,000 times in the past 100 years. When they attempt to build something new, it often ends up like software – tremendous overruns in both cost and schedule. C.f. the only new nuclear power plant being built in the West, which is $4 billion over budget and ten years late: https://en.wikipedia.org/wiki/Olkiluoto_Nuclear_Power_Plant#Unit_3 https://en.wikipedia.org/wiki/Olkiluoto_Nuclear_Power_Plant#... The reason why this feels more commonplace in software is that we're usually designing something new. Software has essentially no reproduction costs, so there's no reason for anybody to design software that's a carbon copy of something you can already download or buy off-the-shelf. That's not the case in engineering of physical products or works. New buildings are needed all the time, even if they're performing exactly the same function as the building in the adjacent lot.

augustl 8y ago
> It's like that in other fields of engineering too, when they are making something they haven't built before. Exactly this. I like to use an analogy of building bridges :) - OK, we have this valley and we want to drive cars over it. What do we do? - Hmm, we could just make the road along the bottom of the valley - Wouldn't that cause the cars to fall because of the steep angle? - Good point. Maybe if we built the road with a lot of twist and turns - Then it's a slow and long drive. - Maybe we could build some sort of catapult setup to throw the cars across the valley - That would make safety a concern though. Is there a way we could use helicopter rotors to suspend a road in mid air over the valley? - Or what if we attach the road to each side of the valley and make a road that's strong enough to not crack in the middle under its own weight? - Yeah, that sounds like a good idea. How do we make sure it can hold its own weight, though? - .....etc
- exikyut 8y ago
  Very interesting point. I must admit that when I saw valley in > OK, we have this valley I immediately thought about SV, and then as I read > - Maybe we could build some sort of catapult setup to throw the cars > * across the valley* I imagined some kind of scenario happening in an alternate reality where a startup was trying to dream up a viable way to actually achieve this in SV. It was funny because of the fact that a lot of the ideas people do come up with are probably ideologically very similar in magnitude and ridiculous impossibility.

z3t4 8y ago

The larger a code base grows, the worse it will get. Once in a while you get a problem that can only be solved by a "hack". And once in a while you need to make performance optimizations. Then time goes by, things are forgotten, the language changes, the OS get replaced, the machine gets replaced, etc.

mbrock 8y ago

I think a lot of programming could be described as "formalizing the logic of a business" which is a very strange and interesting problem. Programming also involves things like "formalizing and automating the representation of knowledge in general" which is a holy grail of philosophy since Leibniz's time. We're always building on top of preexisting ontologies and logics which sometimes fail to even make sense, or which make it tedious to express things that we would want to consider elementary (Unix, TCP, Java, GTK+, SQL, etc). And we're always vulnerable to being smacked on the head by yet another "Falsehoods Programmers Believe About X" post detailing the myriad ways in which we routinely falsify and oversimplify to deal with the boundless complexity of actual reality and the horrendous details of legacy bureaucracy.

croo 8y ago

There is one fundamental difference between software engineering and any other type of engineering. It's that the feedback of the rules that govern the outcome is instant and received by multiple human senses. If you hit something with a hammer the result and response is instant. You can feel the nail went deeper before you look, you can hear you hit the head correctly before you think about it. You can feel the vibration and hear and feel and see the wood crack before you could read a sentence about it. You don't have to compile the hammer and run the hit and read the result from the screen and if you logged the right things you will see something about the result based on what you logged but not quite everything because that would be an unintelligible mess. If you compiled the right version of hammer that is. You don't even know for sure if you are holding a hammer. Of course that's not called a hammer but a unique tool you downloaded because they said it is the new best tool of the year - and there are several famous new tools every year. Though you cannot be sure if that tool helps in your job until you try to use it as you don't know if you are using a hammer or an excavation machine and both can be suitable for the task one being slightly bigger though.

eV6ahne6bei 8y ago

> I always wonder if it's like this for other branches of engineering too? EE here. It's not. The entry bar is much higher: most of the time difficult projects are given to senior engineers. It takes a degree and many years of work to get there. > Or chemical engineers synthesize medicines in way nobody but a rockstar guru understands Been there. Not at all. > cellphone is made by machines designed in early 1990s because nobody was able to figure out what that one cog is doing Same. Part of the reason is that any physical component adds cost, weight, and so on to a project. In software you can throw code and random libraries at a problem and nobody will notice until vulnerabilities start to pop later on.

jonathanstrange 8y ago

Not exactly relevant to the overall discussion but I've been dreaming for a long time about programming an elevator such that it arrives faster and skips other floors if a user frantically pushes the call button repeatedly. Same for traffic lights with push buttons. Maybe it's a good thing that I'm not an engineer.

exikyut 8y ago
There are apocryphal stories about elevators that let you push/hold buttons to cancel floor selections (eg, https://www.youtube.com/watch?v=eQSdKe5kArA https://www.youtube.com/watch?v=eQSdKe5kArA) or skip floors. I often forget to try them, but on the few occasions I've remembered nothing has happened. All elevators accept a standardized fire/security key that enables "exclusive" mode that lets you tell the lift "go to this floor" and it will do so: https://www.youtube.com/watch?v=1Uh_N1O3E4E https://www.youtube.com/watch?v=1Uh_N1O3E4E (a reasonable sink of 1hr) As for traffic lights I'm aware (at least in Australia) that they all tie back to a realtime system that lets a control room instruct lights to turn green and so forth. (Presumably the immediate action is that the lights that are currently green immediately turn orange, then red after the normal delay.) You can get summarily fired for misusing this though. I've also heard (IIRC on a TV documentary-type show) that ambulances tie into this system with live GPS tracking such that lights turn green as they approach, but this is sufficiently fantastic that I'm waiting to trust-but-verify it before I quote it with confidence. Under normal use some traffic lights are traffic based while others have timers. The ones that are traffic based will take into consideration whether the pedestrian crossing button has been pushed and reduce the threshold value needed for the actual traffic lights to turn red. The other timer ones - like the really annoying ones outside my local mall :) - are on a fixed timer, and I try to run for that one when I know it's about to turn green, or just accept and twiddle my fingers while I wait if I miss it. It'd be nice if elevator simulators were satisfying to write. Although, actually... I've just realized that with Unity you could have _quite_ a lot of fun :D... (hmm, I've had GPU on my wishlist for about 15 years now, now I really want one)

packetpirate 8y ago

One reason is that there's still a divide in understanding of the requirements to actually solve a problem between management and the engineering team. Unrealistic deadlines are given, and as a result, shit is produced.

yarg 8y ago

I don't think it's any of the reasons that you listed. To a large extent, I blame management - they push sub-optimal solutions because it's generally the fastest way to resolve the immediate problem. This generally results in poor solutions being piled up on top of each other that becomes progressively more impossible to maintain. This despite the fact that if additional time were allocated to come up with a better solution, tomorrow's software would be easier to integrate on top of today's, and with a higher quality of code. But the reason that managers behave like this is because they can - and this I think has more to do with the ethereal and timeless nature of software than anything else. In the real world it simply is not possible to put together a physical artifact with the sort of compromised constructs that appears in software. There are costs of material to consider; costs of production. There's degradation over time. All of these aspects of physical constructs provide a strong motivation to produce a quality product - not out of beneficence, but because (quality engineers aside) it's cheaper and it's really the only feasible option.

forgottenpass 8y ago

We have plenty of ideas on how to write code well. The catch is that they all make development slower and more expensive (at least up front, maybe the technical debt will come back to bite, maybe not).

timdellinger 8y ago

Chemical synthesis of medicine is highly scrutinized and fairly well understood, but there are a lot of other products that large chemical companies make in great quantity that are basically made using Black Magic. Tinker with it until it works, then don't mess with it!