5 ms·

> Programming is engineering Is it? Genuine question that I've been asking myself for the past several years: In what senses is software engineering actually

> Programming is engineering Is it? Genuine question that I've been asking myself for the past several years: In what senses is software engineering actually an engineering discipline? If you make a project trade-off for the sake of code maintainability, is that based on empirically tested knowledge or following a design pattern guided by an artisan's intuition about how code will be interpreted?

hnuser847 5y ago
I truly think it's more craft than engineering, and even that's somewhat generous. It's mostly guesswork, hacks, inter-team politics, and trend chasing. Imagine an engineering team designing a toaster. They have real constraints to consider, like physically fitting all of the components inside a single package and selecting materials that won't melt during operation. They have to ensure that product won't injure the user or light their house on fire. They have to carefully consider the lifespan of each component and design the product to last for a minimum number of years. The consequences of failing to do these things could potentially result in lawsuits, recalls, injuries, or even death. Now take the average web product. There are no real constraints whatsoever - almost everything comes down to opinions over aesthetics. Even the speed and reliability of the application is somewhat unimportant. Planning ahead is explicitly discouraged. Instead, software "engineers" are encouraged to be agile, move fast and break things, iterate based on feedback/complaints, and push out hotfixes when bugs occur. Software is expected to rot and be rewritten every 3-5 years in the latest language du jour. I could go on and on, but anyone who's been in this industry for more than a few years knows what I'm talking about.
- CRConrad 5y ago
  > Imagine an engineering team designing a toaster. Heh... That supports TFA's point (if taken broadly as "old tech was better tech") in yet another way: Harking back to the famous Technology Connections YouTube video, the best toaster ever was conceived sometime in the 1940s or 50s.
- afarrell 5y ago
  Right. Software is more like a form of artistic/literary expression. We can fight this and find ourselves confused and frustrated. Or we can embrace this and start adopting the techniques of the worlds of art and literature. * Design Crits as an available alternative to doing code reviews solo -- https://digitalblog.coop.co.uk/2018/03/28/how-to-run-a-design-crit-and-why-theyre-important/ https://digitalblog.coop.co.uk/2018/03/28/how-to-run-a-desig... * Embrace writing first drafts and then revising them -- https://twitter.com/paulg/status/1363503835390558208 https://twitter.com/paulg/status/1363503835390558208
- qayxc 5y ago
  > Software is expected to rot and be rewritten every 3-5 years in the latest language du jour. That's simply not true in general. There are plenty of fields where this is not the case. Control software for airplanes, power plants, medical implants, military equipment, etc.; also banking- and insurance software, certain scientific HPC libraries, software for spacecraft (especially deep space missions) and so on. The software world doesn't just consist of web development, cloud computing, and cheap consumer products :) Ten years ago I did some consulting for a large merchant wholesaler and their backend ran on IBM mainframes. At some point I was maintaining CICS programs written in high level assembly with changelogs dating back to 1984 (after getting some coaching from the resident senior programmer first). This was a multi-billion dollar business and the software had to work. 24/7, 365 days a year. Every minute the system was down cost thousands of dollars. If you managed to mess up the system controlling the warehouse logistics, monetary loss was the least of your concerns, though - a dozen angry truck drivers asking for the guy in IT who messed up their schedule was far scarier :D So yeah, in environments like this, every little change or update had to be carefully planned and agreed upon by all stakeholders from all departments.
qayxc 5y ago
This is a question I've struggled with ever since I started working in the field. In terms of definition, software development ticks all the boxes - depending on who you ask. Yet every way you look at it, something just doesn't feel right. Sure, there's best practices, models, a strong mathematical foundation, but on the other hand there's way too much freedom. By "freedom" I strictly mean lack of limitations. While the laws of physics dictate what can and can't be done in traditional engineering disciplines, the same cannot be said about software. A good design can be quantified, tested, and improved based on hard data (and eventual failure). A good program, however, is super hard to qualify. What even is "good maintainability" in terms of software? Is it a bunch of metrics like cyclomatic complexity, Halstead volume, and lines of code haphazardly cobbled together to form an arbitrary index value? With traditional engineering you have material properties like tensile strength that you can match against requirements and safety margins. What's the equivalent of tensile strength of a software product and can we measure it? For decades people in scientific computing have relied on Fortran programs that defy any modern notion of maintainability. The subroutines and "drivers" are limited to 6-character names and functions with >25 arguments are not uncommon. Yet they still work, are still used and stood the test of time despite archaic properties [0], which require users to memorise large tables of codes for data types and routine names. I also feel that despite these limitations, libraries like LAPACK are more readable and maintainable than modern C++ monstrosities like this [1]. [0] http://www.netlib.org/lapack/lug/node24.html http://www.netlib.org/lapack/lug/node24.html [1] https://github.com/nlohmann/json https://github.com/nlohmann/json
- afarrell 5y ago
  > Sure, there's best practices, models, a strong mathematical foundation, but on the other hand there's way too much freedom. I wonder if the same could be said of animation.
- nyanpasu64 5y ago
  Honestly I like well-designed modern C++ as a library/app developer; it's fast, type-safe, and (more or less) expressive. The worst thing about it is unnecessarily complex syntax/concepts (TMP scares me, `template<typename> using Foo` simplifies code, concepts are complicated but help avoid TMP) and slow compile times (unavoidable to my knowledge) I looked at nlohmann/json's homepage and I find the API surface perfectly readable (if you avoid ""_json and the more complex stuff, I didn't look at the library itself). Similarly I think that fmtlib is a beautiful piece of software (fmt::memory_buffer is beautiful, but I dislike the mysterious template errors when you write code wrong, and poor documentation for how to avoid them). It's as convenient as C format strings (but type-safe, and thankfully uses fat strings composed of a pointer and length, or begin and end, rather than null-terminated strings with O(n) strlen), and much better than C++ streams, which hold string formatting state (setw, precision) which is wholly wasteful for binary file IO, and is evil global state (possibly TU-local) for console IO. Modern C++ also a lot better than the 3+ layer deep inheritance hierarchies of 2000s C++, where Child::f() delegates to Base::f() which calls g(), which is a virtual function pointing to Subclass::g(), which delegates to Base::g(), which is alive and well in Qt and KDE code.
kristjansson 5y ago
All code is craft; the systems they implement are engineering.
Koshkin 5y ago
Programming and Software Engineering are related but not the same thing. There is yet another thing - coding, which is also something else. Yes, software engineers do program, and programming involves coding. But someone who has come up with, say, a computational algorithm or a formula may ask you to implement it in a form that a computer (or, more likely, a compiler) can understand. That’s coding. Programming, on the other hand, is what we do when we need to solve a specific problem, or a part of a problem, by writing a program or a library of modules, which involves several steps such as choice of data structures and algorithms that make it possible to solve the problem efficiently. Finally, software engineering is building software from various, potentially many, pieces which include custom program modules as well as those written by third parties. The degree of “engineering” involved grows exponentially as we go from mere coding to programming to, well, software engineering.

hnuser847 5y ago

I truly think it's more craft than engineering, and even that's somewhat generous. It's mostly guesswork, hacks, inter-team politics, and trend chasing. Imagine an engineering team designing a toaster. They have real constraints to consider, like physically fitting all of the components inside a single package and selecting materials that won't melt during operation. They have to ensure that product won't injure the user or light their house on fire. They have to carefully consider the lifespan of each component and design the product to last for a minimum number of years. The consequences of failing to do these things could potentially result in lawsuits, recalls, injuries, or even death. Now take the average web product. There are no real constraints whatsoever - almost everything comes down to opinions over aesthetics. Even the speed and reliability of the application is somewhat unimportant. Planning ahead is explicitly discouraged. Instead, software "engineers" are encouraged to be agile, move fast and break things, iterate based on feedback/complaints, and push out hotfixes when bugs occur. Software is expected to rot and be rewritten every 3-5 years in the latest language du jour. I could go on and on, but anyone who's been in this industry for more than a few years knows what I'm talking about.

CRConrad 5y ago
> Imagine an engineering team designing a toaster. Heh... That supports TFA's point (if taken broadly as "old tech was better tech") in yet another way: Harking back to the famous Technology Connections YouTube video, the best toaster ever was conceived sometime in the 1940s or 50s.
afarrell 5y ago
Right. Software is more like a form of artistic/literary expression. We can fight this and find ourselves confused and frustrated. Or we can embrace this and start adopting the techniques of the worlds of art and literature. * Design Crits as an available alternative to doing code reviews solo -- https://digitalblog.coop.co.uk/2018/03/28/how-to-run-a-design-crit-and-why-theyre-important/ https://digitalblog.coop.co.uk/2018/03/28/how-to-run-a-desig... * Embrace writing first drafts and then revising them -- https://twitter.com/paulg/status/1363503835390558208 https://twitter.com/paulg/status/1363503835390558208
qayxc 5y ago
> Software is expected to rot and be rewritten every 3-5 years in the latest language du jour. That's simply not true in general. There are plenty of fields where this is not the case. Control software for airplanes, power plants, medical implants, military equipment, etc.; also banking- and insurance software, certain scientific HPC libraries, software for spacecraft (especially deep space missions) and so on. The software world doesn't just consist of web development, cloud computing, and cheap consumer products :) Ten years ago I did some consulting for a large merchant wholesaler and their backend ran on IBM mainframes. At some point I was maintaining CICS programs written in high level assembly with changelogs dating back to 1984 (after getting some coaching from the resident senior programmer first). This was a multi-billion dollar business and the software had to work. 24/7, 365 days a year. Every minute the system was down cost thousands of dollars. If you managed to mess up the system controlling the warehouse logistics, monetary loss was the least of your concerns, though - a dozen angry truck drivers asking for the guy in IT who messed up their schedule was far scarier :D So yeah, in environments like this, every little change or update had to be carefully planned and agreed upon by all stakeholders from all departments.

qayxc 5y ago

This is a question I've struggled with ever since I started working in the field. In terms of definition, software development ticks all the boxes - depending on who you ask. Yet every way you look at it, something just doesn't feel right. Sure, there's best practices, models, a strong mathematical foundation, but on the other hand there's way too much freedom. By "freedom" I strictly mean lack of limitations. While the laws of physics dictate what can and can't be done in traditional engineering disciplines, the same cannot be said about software. A good design can be quantified, tested, and improved based on hard data (and eventual failure). A good program, however, is super hard to qualify. What even is "good maintainability" in terms of software? Is it a bunch of metrics like cyclomatic complexity, Halstead volume, and lines of code haphazardly cobbled together to form an arbitrary index value? With traditional engineering you have material properties like tensile strength that you can match against requirements and safety margins. What's the equivalent of tensile strength of a software product and can we measure it? For decades people in scientific computing have relied on Fortran programs that defy any modern notion of maintainability. The subroutines and "drivers" are limited to 6-character names and functions with >25 arguments are not uncommon. Yet they still work, are still used and stood the test of time despite archaic properties [0], which require users to memorise large tables of codes for data types and routine names. I also feel that despite these limitations, libraries like LAPACK are more readable and maintainable than modern C++ monstrosities like this [1]. [0] http://www.netlib.org/lapack/lug/node24.html http://www.netlib.org/lapack/lug/node24.html [1] https://github.com/nlohmann/json https://github.com/nlohmann/json

afarrell 5y ago
> Sure, there's best practices, models, a strong mathematical foundation, but on the other hand there's way too much freedom. I wonder if the same could be said of animation.
nyanpasu64 5y ago
Honestly I like well-designed modern C++ as a library/app developer; it's fast, type-safe, and (more or less) expressive. The worst thing about it is unnecessarily complex syntax/concepts (TMP scares me, `template<typename> using Foo` simplifies code, concepts are complicated but help avoid TMP) and slow compile times (unavoidable to my knowledge) I looked at nlohmann/json's homepage and I find the API surface perfectly readable (if you avoid ""_json and the more complex stuff, I didn't look at the library itself). Similarly I think that fmtlib is a beautiful piece of software (fmt::memory_buffer is beautiful, but I dislike the mysterious template errors when you write code wrong, and poor documentation for how to avoid them). It's as convenient as C format strings (but type-safe, and thankfully uses fat strings composed of a pointer and length, or begin and end, rather than null-terminated strings with O(n) strlen), and much better than C++ streams, which hold string formatting state (setw, precision) which is wholly wasteful for binary file IO, and is evil global state (possibly TU-local) for console IO. Modern C++ also a lot better than the 3+ layer deep inheritance hierarchies of 2000s C++, where Child::f() delegates to Base::f() which calls g(), which is a virtual function pointing to Subclass::g(), which delegates to Base::g(), which is alive and well in Qt and KDE code.

kristjansson 5y ago

All code is craft; the systems they implement are engineering.

Koshkin 5y ago

Programming and Software Engineering are related but not the same thing. There is yet another thing - coding, which is also something else. Yes, software engineers do program, and programming involves coding. But someone who has come up with, say, a computational algorithm or a formula may ask you to implement it in a form that a computer (or, more likely, a compiler) can understand. That’s coding. Programming, on the other hand, is what we do when we need to solve a specific problem, or a part of a problem, by writing a program or a library of modules, which involves several steps such as choice of data structures and algorithms that make it possible to solve the problem efficiently. Finally, software engineering is building software from various, potentially many, pieces which include custom program modules as well as those written by third parties. The degree of “engineering” involved grows exponentially as we go from mere coding to programming to, well, software engineering.