4 ms·

Can you give an example of something specific he says that you disagree with?

by kradic 19y ago

pius 19y ago
Heh, upon review of what I said, it probably came off as too harsh. I was so terse because I didn't feel like writing a long polemic at the time I made the comment. :) Now that I have a minute, here are some of the points I disagreed with in the essay. "Unfortunately . . . software development and engineering are, even at the most fundamental parts, completely different. Engineering is the practice to develop something touchable, something that obeys the laws of physics." That premise is flawed and leads to misguided conclusions. Engineering is the application of technical knowledge to solve problems. There are tons of ways to say this, depending on who defines it, but no reasonable definition prima facie excludes software from being an engineering discipline. This implies that the product produced can be evaluated with the laws of physics. You can make all kinds of statistics, strength calculations, etc on the product. . . . . Software on the other hand, doesn't obey the laws of physics, by the simple reason because it can't be touched. Sure, it has physical parts, but those physical parts are not that important. Let's forget for a second that all software can be specified in hardware. There are still important "physical parts," constraints, and metrics applicable to the design of software. For instance, one would be hard pressed to argue that physical constraints of RAM and processor speed are completely irrelevant to software. In addition, much of software engineering actually turns out to be how to optimize output of teams with finite amounts of man-hours available. This is non-trivial and subject to a wealth of metrics, experimentation, and methodologies. But let's go even further and put all of that aside. The argument still doesn't hold up. Even if software could not be touched, it could still can be engineered. Disciplines like process engineering and human factors engineering are examples of rigorous practices applied to seemingly abstract implementations. Useful software engineering principles such as modularity, coupling, cohesion, reuse, interfaces, specifications all come directly from other "traditional" engineering practices and have been shown to improve the quality and speed of software development. Look, I appreciate the art of software development; that's part of what I love about it! And there's certainly a point to be made about focusing too much on process over creativity at the wrong stages. But that point wasn't made. The article seemed to suggest that we just throw up our hands and give up trying to do anything rigorous with the products we design because it's all an illusion anyway. I think we can do better than that. We need to do better than that.
- dewitters 19y ago
  My point in the article is also that we can and need to do better (maybe not clearly explained ;), but it is my belief that using the "engineering" metaphor will hold us back. A lot of people, maybe even most, believe that we should improve ourselves by becoming "more like engineers". For example by using Formal Methods etc. This might be true for a small number of projects, but it is my believe that for most software projects, as software developers we need to become "less like engineers". "Engineering is the application of technical knowledge to solve problems.", therefore, engineers try to gain as much technical knowledge as possible to solve their problems. In my opinion software development should evolve to require less and less technical knowledge, that way we can spend more effort on the real problem: mapping the problem domain into a clear software representation. Developing software should evolve closer towards the human side, and not towards the technical side. And so far, programming languages for example have evolved in that direction.

Can you give an example of something specific he says that you disagree with?

by kradic 19y ago

Can you give an example of something specific he says that you disagree with?

pius 19y ago

Heh, upon review of what I said, it probably came off as too harsh. I was so terse because I didn't feel like writing a long polemic at the time I made the comment. :) Now that I have a minute, here are some of the points I disagreed with in the essay. "Unfortunately . . . software development and engineering are, even at the most fundamental parts, completely different. Engineering is the practice to develop something touchable, something that obeys the laws of physics." That premise is flawed and leads to misguided conclusions. Engineering is the application of technical knowledge to solve problems. There are tons of ways to say this, depending on who defines it, but no reasonable definition prima facie excludes software from being an engineering discipline. This implies that the product produced can be evaluated with the laws of physics. You can make all kinds of statistics, strength calculations, etc on the product. . . . . Software on the other hand, doesn't obey the laws of physics, by the simple reason because it can't be touched. Sure, it has physical parts, but those physical parts are not that important. Let's forget for a second that all software can be specified in hardware. There are still important "physical parts," constraints, and metrics applicable to the design of software. For instance, one would be hard pressed to argue that physical constraints of RAM and processor speed are completely irrelevant to software. In addition, much of software engineering actually turns out to be how to optimize output of teams with finite amounts of man-hours available. This is non-trivial and subject to a wealth of metrics, experimentation, and methodologies. But let's go even further and put all of that aside. The argument still doesn't hold up. Even if software could not be touched, it could still can be engineered. Disciplines like process engineering and human factors engineering are examples of rigorous practices applied to seemingly abstract implementations. Useful software engineering principles such as modularity, coupling, cohesion, reuse, interfaces, specifications all come directly from other "traditional" engineering practices and have been shown to improve the quality and speed of software development. Look, I appreciate the art of software development; that's part of what I love about it! And there's certainly a point to be made about focusing too much on process over creativity at the wrong stages. But that point wasn't made. The article seemed to suggest that we just throw up our hands and give up trying to do anything rigorous with the products we design because it's all an illusion anyway. I think we can do better than that. We need to do better than that.

dewitters 19y ago
My point in the article is also that we can and need to do better (maybe not clearly explained ;), but it is my belief that using the "engineering" metaphor will hold us back. A lot of people, maybe even most, believe that we should improve ourselves by becoming "more like engineers". For example by using Formal Methods etc. This might be true for a small number of projects, but it is my believe that for most software projects, as software developers we need to become "less like engineers". "Engineering is the application of technical knowledge to solve problems.", therefore, engineers try to gain as much technical knowledge as possible to solve their problems. In my opinion software development should evolve to require less and less technical knowledge, that way we can spend more effort on the real problem: mapping the problem domain into a clear software representation. Developing software should evolve closer towards the human side, and not towards the technical side. And so far, programming languages for example have evolved in that direction.