A lot of programmers talk about K.I.S.S (Keep It Simple Stupid) when it comes to writing their software but don't extend that to their build tools, or how they

A lot of programmers talk about K.I.S.S (Keep It Simple Stupid) when it comes to writing their software but don't extend that to their build tools, or how they deploy it. Just like the "you are not google talk"^1 people tend to overengineer solutions for a problem they could have in the future. I'm certainly guilty of this. At work I can't just write some python code in an editor, I have to write and pass around Jupyter Notebooks. Or worse I have to launch a Jupyter Notebook inside a Docker container so that it loads the correct dependencies. I understand this is done to make things more reproducible but we've still had issues getting clients set up in our workflow even using this method. I will be the first to admit I am a noob when it comes to systems programming, but I found it so frustrating when I attempted to learn C and C++ having to download and use Make, Cmake, Ninja etc, vcpkg, just to interface with other peoples code. And it was never just as simple as running the install script. A great example is Raylib on the PI4. The majority of Pis are running Raspbian/Raspberry PI OS and the only thing that changes between PI 4s is the amount of memory. So this should be the best case scenario for creating a install script. The raylib documentation says it should only require a couple Make commands. I ran them and it still failed. I appreciate how D and Rust both have Cargo and Dub. While they have their warts, it makes it sooo much easier to link and install other peoples code, and import/use it in your code. When the languages and problems are hard enough, I don't want to be futzing around with linking and dependency management. With how much people complain about software licensing, because they don't want to have to thing about the code they are using in their project, I think about the install process. And in regards to things being slower and breaking now a days compared to back in the day... I can't comment on that. I'm too young to remember what software was like back in the 80s and 90s, I just hear what older people tell me. I know Casey Muratori has an example of the watch window in Visual Studio being worse today then it was in the Windows XP^2 days. There are probably other examples. What I do know is this. Programs I open on my desktop fail to open, or crash unexpectedly all the time. A great example of this is Webex Teams, which I have to use everyday at work. I don't think people question that software in some cases is doing much more complicated stuff then it was doing 30 years ago, but I think people also have an expectation that it would be more stable than it was 30 years ago. I mean... People used to write programs on computers without memory protection! When before I can use a piece of software I have to sign in to my account, which has to authenticate in the cloud, that software is objectively slower than the version that I could use which did not require a login, but for me to purchase the actual software. It doesn't matter how much better, or more complex it is now, that process only exists so that the Company can fight piracy, and exert control over the product. It does not serve Me. 1.https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb 2. https://youtu.be/GC-0tCy4P1U?t=2170 https://youtu.be/GC-0tCy4P1U?t=2170