@hwayne engineering signal! The dude did a whole study asking people who work in both software and non-software engineering what they think of that. The short version is that traditional engineering is a lot less slick than you think and people in traditional engineering think software engineering has some cool practices they would adopt if they could.
Here’s a very important and tangible difference between “real” (or “trad” if you prefer) engineering and “software engineering”. If you’re a civil, chemical, structural, or even an electrical engineer, you are a member of a professional society. You may have some choice about which society you join, but not being a member is not really an option. Your professional society polices itself, funds research, sets industrial “best practices” with legal teeth, and should protect you from your employer if they ask you to do something unethical. When you sign off on an engineering document, you are putting your professional reputation on the line.
This was hard-won, historically. We had a lot of floods, trainwrecks, bridge collapses, etc. on the way here. I don’t think computing has reached the point where we can professionalize, but it’s a well trod path.
Git clone it, it’s basically identical to what I left… The added complexity (when present) is inside the modules directory and normally it does not even build. You just download Redis and type “make”, without deps, as usually.
You might think this is obvious, but intentions matter. If you want to build less complex software, you need to make it an explicit goal and plenty of developers and companies do not make it one. The default behavior of any system is to gain complexity.
I sometimes wonder if it’s just the aspect of getting older that makes software seem like it’s getting worse. Software was certainly simpler in my time, but it didn’t do a lot of the things that software does today. Both bad and good. I couldn’t have imagined having 32 processors available on a user system back in 1980. Now it’s commonplace. Kind of like the car, things have advanced to the point where things are better and worse.
I don’t have a full answer for you, but one of the subjective aspects of software that I find gets worse over time is that I feel that there is a “greater distance” between myself, the software, and my data.
For example, if I want to count how many pdf files I have in my home directory on my home computer, it’s a simple incantation: find ~ -name '*.pdf' | wc -l. It’s easy, fast, and it uses the great capability of Unix pipelines to pass data through multiple filters.
If I wanted to do the same, but for files in an S3 bucket, I need to use the web UI and hope that I can do a search or filter and that the UI will show how many objects matched. I could also try to use the awscli tool to have a stream of bytes that I can pipe into grep | wc -l to make the task more Unixy. In either case, I can’t start obtaining the information until I’ve authenticated with MFA.
In this example, going from “I have a question” to “I have an answer” is much faster and much less of a hassle in the desktop scenario than in the web service scenario, because the “distance” between myself and my data is much shorter. If the S3 approach is annoying enough, I might avoid finding answers to my questions.
In the past 10-15 years, as software has migrated from the desktop to the web, our ability to manipulate our data quickly, easily, and flexibly has diminished greatly. Even on our phones, managing simple files and their content can feel out of reach. And unfortunately, it seems that more of our daily experience must be done with software where it feels like you are not the owner of your data, but just a customer who can do with his data what the SaaS provider has deemed you can do.
I can’t start obtaining the information until I’ve authenticated with MFA.
Surely you also sign in to the Unix-like OS on your home computer before running find? Likely you use fewer factors of authentication than for AWS, but I guess it’s a difference between two factors and one factor rather than two and zero.
Modern software seems much more difficult to automate. Web/cloud are the worse for this. The default way to repeat anything is to manually perform the action again, and again, and again…
APIs are all very well, but typically take significant programming to use. Oh for an equivalent to “find ~ -name '*.pdf' | wc -l” for normal (or unusual) actions.
If I wanted to do the same, but for files in an S3 bucket, I need to use the web UI and hope that I can do a search or filter and that the UI will show how many objects matched. I could also try to use the awscli tool to have a stream of bytes that I can pipe into grep | wc -l to make the task more Unixy. In either case, I can’t start obtaining the information until I’ve authenticated with MFA.
In my experience, one needs to push a bit for things to become simple again, but it is often possible. Another option in your example is to use s3fs-fuse, which will let you mount a bucket just like any other external storage. Then find ~ -name '*.pdf' | wc -l simply works as it did before.
It is a simple one-time install. You do have to set up the MFA, that is true. But I would argue that security is one of the things that has gotten better over the years.
I guess cuz I kind of divorced myself from most of the cloud stuff. Although I do it at work, most of my personal stuff is just standard documents that I sell post and backup both on the cloud and locally. I do understand that sentiment though. For most normal folk it’s probably true.
It’s the same complaint about bloat, needless complexity, and inefficient fancy new language features, but being an artifact of its time, it complains about software needing 1MB of RAM when back in his days 32KB would suffice.
Mmm maybe but, you are talking with somebody very enthusiastic with AI developments for instance. I’m very interested in new things and new technologies. The complexity I’m referring here, like the one of web frameworks to take an example, or the absurd dependencies chain, has nothing to do with cool new things, it is just “free” complexity, where you do what you could easily do without such a mess.
I probably agree with most of this, but man, this point is hard to get my head around:
We are destroying software with complex build systems.
Most of the modern build systems are far, far simpler than the bespoke build systems people would build with Make or generate with CMake or Automake or whatever. I can jump into almost any project and run go build or cargo build and it will do pretty much exactly what I expect. I don’t have to take great care that I have exactly the right set of libraries installed at exactly the right versions, and the build tools don’t have to delegate to some special program whose entire reason for existing is making educated guesses about where dependencies might live on my filesystem. These tools take a bit of static configuration, rather than a cobbled-together, imperative, stringly-typed configuration language (in the case of CMake, one with special first-class knowledge of certain dependencies).
I don’t understand how anyone could, with a straight face, argue that build tooling has become more complex. Maybe they’re thinking about “build tooling” differently than I am.
I don’t understand how anyone could, with a straight face, argue that build tooling has become more complex. Maybe they’re thinking about “build tooling” differently than I am.
If I read someone making the claim that we are destroying software with complex build systems, I would assume they were talking about A) frontend tooling or B) autotools. The latter has been a long slow burn but it doesn’t make it less true; people somehow do still use it.
So what makes you think this is criticizing cargo or the go tooling as “complex build systems” and not cmake/various JS tools/…? Not being clear on that IMHO makes this article fairly pointless.
I don’t really know for sure, because the article isn’t clear, but the formulation implies that things have gotten worse and the author is a famed C developer so presumably it seems likely that he is arguing in favor of the old world of bespoke build systems with no dependency management.
I mostly agree, but aren’t a few of these (a little bit) mutually exclusive? Like
We are destroying software telling new programmers: “Don’t reinvent the wheel!”. But, reinventing the wheel is how you learn how things work, and is the first step to make new, different wheels.
versus
We are destroying software pushing for rewrites of things that work.
Like obviously they’re not exact opposites, but re-writing something that works is re-inventing the wheel.
I know its a rant, but it really seems like a list of platitudes that could be taken in way to many different ways to be useful. Surprised it’s getting this much attention?
It’s just a device to give the composition weight. Gravity. There’s not much more to read into it. The bits that follow that phrase are the ones you are meant to focus on.
Haha I loved the “We are destroying software telling new programmers: “Don’t reinvent the wheel!”. But, reinventing the wheel is how you learn how things work, and is the first step to make new, different wheels.”
This is sort of always how I’ve felt. The old wheels are often pretty terrible (looks at make), and I’ve learned so much by making newer, better wheels or even trying and failing to do so.
It doesn’t matter. Computers are slowly being replaced with locked down devices where it is harder and harder to create new software, or even inspect the software that you use in your device.
I don’t even know if this is intentional or accidental; for all the signals that big companies hate that programmers have nice salaries, they are surely also making it harder and harder for people to get into the business.
You don’t seem to see this kind of culture problem in other creative vocations, like woodworking or painting; that or I’m naive. What is it about software that we have collectively removed the sense of ‘honorable craftsmanship’ associated with building software?
Ahhh, I think your blind spot has to do with looking at the hobby side of it vs. the commercial side of it. There are terrible carpenters who, for example, leave huge gaps when framing houses or forget to leave room for the plumbers and electricians, resulting in the downstream trades drilling holes that compromise the structural integrity of the framing. Next time you’re in a public washroom at a restaurant have a look at the (lack of) quality in the wall paint.
I, 30 years in, haven’t given up on the “honourable craftsmanship” side of writing code and am proud to say that I have multiple codebases that are 10+ years old that are still maintainable and sometimes are even a joy to work with. There has to be pragmatism, though. There’s definitely code floating around that I’ve written that I’m not proud of but is still “load bearing” in some sense of the word. And there’s a ton that was written as one-off garbage that was used for 3 days and discarded. The trick is knowing which strategy is the right one in a given moment and making sure that the one-off garbage doesn’t end up in production for a decade :)
Personally, I tend to consider that sometimes we don’t consider enough the engineering discipline when writing software 😅.
We cargo cult “engineering”, but don’t engineer.
@hwayne engineering signal! The dude did a whole study asking people who work in both software and non-software engineering what they think of that. The short version is that traditional engineering is a lot less slick than you think and people in traditional engineering think software engineering has some cool practices they would adopt if they could.
Here’s a very important and tangible difference between “real” (or “trad” if you prefer) engineering and “software engineering”. If you’re a civil, chemical, structural, or even an electrical engineer, you are a member of a professional society. You may have some choice about which society you join, but not being a member is not really an option. Your professional society polices itself, funds research, sets industrial “best practices” with legal teeth, and should protect you from your employer if they ask you to do something unethical. When you sign off on an engineering document, you are putting your professional reputation on the line.
This was hard-won, historically. We had a lot of floods, trainwrecks, bridge collapses, etc. on the way here. I don’t think computing has reached the point where we can professionalize, but it’s a well trod path.
Antirez needed some venting after coming back from vacation and checking what redis looks like nowadays /jk
Git clone it, it’s basically identical to what I left… The added complexity (when present) is inside the modules directory and normally it does not even build. You just download Redis and type “make”, without deps, as usually.
Ah yes, “don’t write complex software”. Why didn’t anyone just tell me that before! It’s so simple! And while we’re at it: don’t write bugs, either!
There, I’ve solved software development. I’m sure there can’t possibly be any more to it than just repeating these mantras.
You might think this is obvious, but intentions matter. If you want to build less complex software, you need to make it an explicit goal and plenty of developers and companies do not make it one. The default behavior of any system is to gain complexity.
I sometimes wonder if it’s just the aspect of getting older that makes software seem like it’s getting worse. Software was certainly simpler in my time, but it didn’t do a lot of the things that software does today. Both bad and good. I couldn’t have imagined having 32 processors available on a user system back in 1980. Now it’s commonplace. Kind of like the car, things have advanced to the point where things are better and worse.
I don’t have a full answer for you, but one of the subjective aspects of software that I find gets worse over time is that I feel that there is a “greater distance” between myself, the software, and my data.
For example, if I want to count how many pdf files I have in my home directory on my home computer, it’s a simple incantation:
find ~ -name '*.pdf' | wc -l. It’s easy, fast, and it uses the great capability of Unix pipelines to pass data through multiple filters.If I wanted to do the same, but for files in an S3 bucket, I need to use the web UI and hope that I can do a search or filter and that the UI will show how many objects matched. I could also try to use the
awsclitool to have a stream of bytes that I can pipe intogrep | wc -lto make the task more Unixy. In either case, I can’t start obtaining the information until I’ve authenticated with MFA.In this example, going from “I have a question” to “I have an answer” is much faster and much less of a hassle in the desktop scenario than in the web service scenario, because the “distance” between myself and my data is much shorter. If the S3 approach is annoying enough, I might avoid finding answers to my questions.
In the past 10-15 years, as software has migrated from the desktop to the web, our ability to manipulate our data quickly, easily, and flexibly has diminished greatly. Even on our phones, managing simple files and their content can feel out of reach. And unfortunately, it seems that more of our daily experience must be done with software where it feels like you are not the owner of your data, but just a customer who can do with his data what the SaaS provider has deemed you can do.
Surely you also sign in to the Unix-like OS on your home computer before running
find? Likely you use fewer factors of authentication than for AWS, but I guess it’s a difference between two factors and one factor rather than two and zero.Modern software seems much more difficult to automate. Web/cloud are the worse for this. The default way to repeat anything is to manually perform the action again, and again, and again…
APIs are all very well, but typically take significant programming to use. Oh for an equivalent to “
find ~ -name '*.pdf' | wc -l” for normal (or unusual) actions.In my experience, one needs to push a bit for things to become simple again, but it is often possible. Another option in your example is to use s3fs-fuse, which will let you mount a bucket just like any other external storage. Then
find ~ -name '*.pdf' | wc -lsimply works as it did before.It is a simple one-time install. You do have to set up the MFA, that is true. But I would argue that security is one of the things that has gotten better over the years.
Do you also find that kids are worse behaved and have stupider haircuts? I know I do, but so has almost every generation of middle aged adult.
I guess cuz I kind of divorced myself from most of the cloud stuff. Although I do it at work, most of my personal stuff is just standard documents that I sell post and backup both on the cloud and locally. I do understand that sentiment though. For most normal folk it’s probably true.
Check out A Plea For Lean Software by Wirth: https://ia801608.us.archive.org/8/items/pdfy-PeRDID4QHBNfcH7s/LeanSoftware_text.pdf
It’s the same complaint about bloat, needless complexity, and inefficient fancy new language features, but being an artifact of its time, it complains about software needing 1MB of RAM when back in his days 32KB would suffice.
Mmm maybe but, you are talking with somebody very enthusiastic with AI developments for instance. I’m very interested in new things and new technologies. The complexity I’m referring here, like the one of web frameworks to take an example, or the absurd dependencies chain, has nothing to do with cool new things, it is just “free” complexity, where you do what you could easily do without such a mess.
I probably agree with most of this, but man, this point is hard to get my head around:
Most of the modern build systems are far, far simpler than the bespoke build systems people would build with Make or generate with CMake or Automake or whatever. I can jump into almost any project and run
go buildorcargo buildand it will do pretty much exactly what I expect. I don’t have to take great care that I have exactly the right set of libraries installed at exactly the right versions, and the build tools don’t have to delegate to some special program whose entire reason for existing is making educated guesses about where dependencies might live on my filesystem. These tools take a bit of static configuration, rather than a cobbled-together, imperative, stringly-typed configuration language (in the case of CMake, one with special first-class knowledge of certain dependencies).I don’t understand how anyone could, with a straight face, argue that build tooling has become more complex. Maybe they’re thinking about “build tooling” differently than I am.
If I read someone making the claim that we are destroying software with complex build systems, I would assume they were talking about A) frontend tooling or B) autotools. The latter has been a long slow burn but it doesn’t make it less true; people somehow do still use it.
So what makes you think this is criticizing cargo or the go tooling as “complex build systems” and not cmake/various JS tools/…? Not being clear on that IMHO makes this article fairly pointless.
I don’t really know for sure, because the article isn’t clear, but the formulation implies that things have gotten worse and the author is a famed C developer so presumably it seems likely that he is arguing in favor of the old world of bespoke build systems with no dependency management.
I mostly agree, but aren’t a few of these (a little bit) mutually exclusive? Like
versus
Like obviously they’re not exact opposites, but re-writing something that works is re-inventing the wheel.
I feel like this isn’t a binary choice. There’s a balance that can be had here.
But with Copilot, we can destroy it 20% faster!
I know its a rant, but it really seems like a list of platitudes that could be taken in way to many different ways to be useful. Surprised it’s getting this much attention?
We should destroy all software.
Yeah, that’s Gary Bernhardt’s schtick.
What’s the point of the the repetition of the phrase “we are destroying software”? Is it because we should:
A lot of these would work fine if just stated as “it’s bad to”. So that’s why I question this specific framing.
It’s just a device to give the composition weight. Gravity. There’s not much more to read into it. The bits that follow that phrase are the ones you are meant to focus on.
Literary device, nothing more.
I don’t know if I’d go as far as all that but it’s true that a switch flipped in me when I understood webpack
Haha I loved the “We are destroying software telling new programmers: “Don’t reinvent the wheel!”. But, reinventing the wheel is how you learn how things work, and is the first step to make new, different wheels.”
Nice rant.
This is sort of always how I’ve felt. The old wheels are often pretty terrible (looks at make), and I’ve learned so much by making newer, better wheels or even trying and failing to do so.
It doesn’t matter. Computers are slowly being replaced with locked down devices where it is harder and harder to create new software, or even inspect the software that you use in your device.
I don’t even know if this is intentional or accidental; for all the signals that big companies hate that programmers have nice salaries, they are surely also making it harder and harder for people to get into the business.
So like. Why are “we” doing these things? Why are they bad? What are the alternatives?
Laughs in capitalism
I dunno, I think these things are mostly true for paid programming. Private projects and open source isn’t quite like that.
Is this guy all right?
You don’t seem to see this kind of culture problem in other creative vocations, like woodworking or painting; that or I’m naive. What is it about software that we have collectively removed the sense of ‘honorable craftsmanship’ associated with building software?
Ahhh, I think your blind spot has to do with looking at the hobby side of it vs. the commercial side of it. There are terrible carpenters who, for example, leave huge gaps when framing houses or forget to leave room for the plumbers and electricians, resulting in the downstream trades drilling holes that compromise the structural integrity of the framing. Next time you’re in a public washroom at a restaurant have a look at the (lack of) quality in the wall paint.
I, 30 years in, haven’t given up on the “honourable craftsmanship” side of writing code and am proud to say that I have multiple codebases that are 10+ years old that are still maintainable and sometimes are even a joy to work with. There has to be pragmatism, though. There’s definitely code floating around that I’ve written that I’m not proud of but is still “load bearing” in some sense of the word. And there’s a ton that was written as one-off garbage that was used for 3 days and discarded. The trick is knowing which strategy is the right one in a given moment and making sure that the one-off garbage doesn’t end up in production for a decade :)