4 ms·

> But no theory needs to exist. You can hack a half assed solution and that's really all that's needed I don't understand your reasoning. You say that it's pos

> But no theory needs to exist. You can hack a half assed solution and that's really all that's needed I don't understand your reasoning. You say that it's possible to "hack a half assed solution" that somehow works and from that you conclude that software is easy (or the easiest, doesn't matter)? Aren't you contracting yourself? If software is easy why do you produce a half-assed solution? If it's so easy why isn't your solution of high quality like the 747? Maybe it's not so easy to write cheap, bug free, portable, maintainable, compatible, little-resource-consuming, high-performing software? I can also build a half-assed airplane. It will crash often, not do what I wanted, and I will use a lot of off-the-shelf components (engine,...), just like modern software... That must mean building airplanes is easy, right? Edit: It would be more correct to say it like this: Creating software is hard and poorly understood at the moment. Even worse, people writing software are not trained well. But since the expectations of our customers are low (compared to the expectations we have to, for example, an airplane), the market tolerates this. Edit 2: By the way, I agree with most of what you have written about the industry moving in circles, half-assed solutions, using patterns and frameworks without any deeper understanding. But that's actually proving that software engineering IS hard. (or maybe it's easy but nobody cares)

deltaonefour 5y ago
>Aren't you contracting yourself? If software is easy why do you produce a half-assed solution? That's why it's easy. Finding a formal theory for software organization is hard so it hasn't been done yet. We make do with design patterns and many of those patterns are outright mistakes. As it stands without "Computer scientists" establishing a formal theory on this... Software engineering is a shot in the dark and therefore easy. >I can also build a half-assed airplane. It will crash often, not do what I wanted, An airplane can only crash once. And when it crashes, people die. That's why no airplane is ever half-assed. Building an airplane is hard because of these requirements. Building software is easy because the requirements ALLOW for it to be half assed. Does my OS crash once a day? Still somewhat useable... Does my plane crash once a day? Holy shit. >Edit: It would be more correct to say it like this: Creating software is hard and poorly understood at the moment. Even worse, people writing software are not trained well. But since the expectations of our customers are low (compared to the expectations we have to, for example, an airplane), the market tolerates this. Hence why Software engineering is one of the easiest engineering disciplines out there. >Edit 2: By the way, I agree with most of what you have written about the industry moving in circles, half-assed solutions, using patterns and frameworks without any deeper understanding. But that's actually proving that software engineering IS hard. (or maybe it's easy but nobody cares) I would argue that this is more, computer science is hard rather than software engineering. The development of new techniques and greater understanding is the domain of science and academia. Engineering is about solving existing problems with existing techniques. Software engineering as it stands is easy.
- ojl 5y ago
  What about safety critical software? For example software running inside airplanes, rockets, etc. Is that also easy, or it doesn’t count because it’s cross discipline? Although I would guess that many of those developers are indeed software engineers and not aerospace engineers by training.
  - deltaonefour 5y ago
    >What about safety critical software? For example software running inside airplanes, rockets, etc. There's two ways of handling software that's safety critical. For software that needs an extreme level of safety... formal methods are employed to prove correctness and that software is bug free. For this part of computer science the foundational theory is well established. This part is really really hard which is why 99% of software engineers don't even know what I mean when I say the word "formal methods." It's so different from traditional software that it's never ever referred to when people use the term "software engineering." We have a rudimentary form of it in the form of type checking in our programming languages. But there's another part of it as well involving empirical testing. This is popular in the industry and engineers use the term unit testing or regression testing to refer to it. It's a shot in the dark. Basically taking a couple test samples out of an huge sample space of possible tests and saying if those samples work then likely the whole thing works. IF you want to prove your program correct using this method you would have to run every single possible test that exists on your program. It's untenable so we informally rely on a statistical phenomenon of taking a sample of tests out of a huge sample space. This is the most common way of creating safety critical software that everyone uses because it's easy. Don't mix tediousness with easy. Using this methodology is very tedious, but I would argue quite easy. Also redundancy and fail-safes in logic are used throughout the system for safety critical software. This again is easy to implement but tedious. >Although I would guess that many of those developers are indeed software engineers and not aerospace engineers by training. Yeah most of the mathematics in this case is modeled by system engineers or other engineers that are more specialized than the math is handed down to the software guys who only need to understand the equations but they don't need to understand how to derive those equations. During testing the software engineers and hardware engineers would have to work together to make sure the software operates the hardware correctly. If the hardware is simple or well established and accessible often the software engineer can do the testing alone. Sometimes the engineer of the physical system itself just programs it himself. Alot of non-software engineers are like this because software engineering tends to be easy so they can just learn how to program.

deltaonefour 5y ago

>Aren't you contracting yourself? If software is easy why do you produce a half-assed solution? That's why it's easy. Finding a formal theory for software organization is hard so it hasn't been done yet. We make do with design patterns and many of those patterns are outright mistakes. As it stands without "Computer scientists" establishing a formal theory on this... Software engineering is a shot in the dark and therefore easy. >I can also build a half-assed airplane. It will crash often, not do what I wanted, An airplane can only crash once. And when it crashes, people die. That's why no airplane is ever half-assed. Building an airplane is hard because of these requirements. Building software is easy because the requirements ALLOW for it to be half assed. Does my OS crash once a day? Still somewhat useable... Does my plane crash once a day? Holy shit. >Edit: It would be more correct to say it like this: Creating software is hard and poorly understood at the moment. Even worse, people writing software are not trained well. But since the expectations of our customers are low (compared to the expectations we have to, for example, an airplane), the market tolerates this. Hence why Software engineering is one of the easiest engineering disciplines out there. >Edit 2: By the way, I agree with most of what you have written about the industry moving in circles, half-assed solutions, using patterns and frameworks without any deeper understanding. But that's actually proving that software engineering IS hard. (or maybe it's easy but nobody cares) I would argue that this is more, computer science is hard rather than software engineering. The development of new techniques and greater understanding is the domain of science and academia. Engineering is about solving existing problems with existing techniques. Software engineering as it stands is easy.

ojl 5y ago
What about safety critical software? For example software running inside airplanes, rockets, etc. Is that also easy, or it doesn’t count because it’s cross discipline? Although I would guess that many of those developers are indeed software engineers and not aerospace engineers by training.
- deltaonefour 5y ago
  >What about safety critical software? For example software running inside airplanes, rockets, etc. There's two ways of handling software that's safety critical. For software that needs an extreme level of safety... formal methods are employed to prove correctness and that software is bug free. For this part of computer science the foundational theory is well established. This part is really really hard which is why 99% of software engineers don't even know what I mean when I say the word "formal methods." It's so different from traditional software that it's never ever referred to when people use the term "software engineering." We have a rudimentary form of it in the form of type checking in our programming languages. But there's another part of it as well involving empirical testing. This is popular in the industry and engineers use the term unit testing or regression testing to refer to it. It's a shot in the dark. Basically taking a couple test samples out of an huge sample space of possible tests and saying if those samples work then likely the whole thing works. IF you want to prove your program correct using this method you would have to run every single possible test that exists on your program. It's untenable so we informally rely on a statistical phenomenon of taking a sample of tests out of a huge sample space. This is the most common way of creating safety critical software that everyone uses because it's easy. Don't mix tediousness with easy. Using this methodology is very tedious, but I would argue quite easy. Also redundancy and fail-safes in logic are used throughout the system for safety critical software. This again is easy to implement but tedious. >Although I would guess that many of those developers are indeed software engineers and not aerospace engineers by training. Yeah most of the mathematics in this case is modeled by system engineers or other engineers that are more specialized than the math is handed down to the software guys who only need to understand the equations but they don't need to understand how to derive those equations. During testing the software engineers and hardware engineers would have to work together to make sure the software operates the hardware correctly. If the hardware is simple or well established and accessible often the software engineer can do the testing alone. Sometimes the engineer of the physical system itself just programs it himself. Alot of non-software engineers are like this because software engineering tends to be easy so they can just learn how to program.