Today, my opinion is that software is grown, not built.
You start with a small thing that mostly works, then throw away what isn't good and add what is missing. In this process, you learn more, so it is iterative.
The main reason projects fail is not technological. The real killers are lack of analysis and lack of communication. Both are a lot easyer with 1 enthousiast doing the whole project.
It’s a mistake to think that there is a singular optimum perfect way to build software that will work for all people in all contexts. The reality is that there are many wonderful and different ways to build software that all works for some developers in some contexts. The general lack of understanding of this fundamental truth is what leads to useless flame wars and claims about X being a better way to build software than Y. Figure out what works for you and your team. Experiment with changes to see if that improves your productivity. Keep what works. Repeat. That’s the Way.
> Most of the critics of waterfall haven't actually worked in such a project.
I wouldn't say that's true.
> Most of the critics of either C or javascript haven't actually built anything noteworthy with it.
That's oddly out-of-place gatekeeping. I've built large things in C 25 years ago that didn't get finished or weren't put in production. That's enough to learn about C, at the time.
> Most of the critics of OOP don't have much practical experience with it
I wouldn't say that's true.
I read a collection of thoughts that feels like a combination of imposter syndrome (20 applications in 20 years? yeesh, that's sparse) and blanket characterization through arbitrary gatekeeping. I understand what they are getting at.
This sort of critique about software development practice critique was better covered in "What We Think We Know About Software Development and Why We Believe it’s True."[1] - https://www.youtube.com/watch?v=I0Pt9Lf9JzQ
[1]
About 18 months ~ 2yrs ago, all copies of this keynote were scrubbed from the internet as part of Greg Wilson capitalizing on his geek-fame with an Oreilly book and appearances. Recently, there has been an explosion of Greg Wilson videos on youtube. Not sure how long it will last. Similar information is presented in this updated, broad presentation that Greg Wilson put up: https://www.youtube.com/watch?v=HrVtA-ue-x0 and there's a PDF and a dry, stale version of the keynote presentation that I can't find again.
Yeah, I don't criticize Waterfall because I've never seen it or been part of it. I criticize it because I watched several million dollar mistakes happen under Waterfall process projects and one multi-billion dollar mistake (years late and they delivered the wrong thing, brilliant!).
When I first got into Linux it was circumstantial. I was 11 and trying to figure out how to put "free games" (homebrew) on my console and that got me into installing Linux.
Back in those days (20 years ago) we didn't have the rich package managing ecosystems of today or fast internet access. I bought a Linux CD from a local computer store (though I called it Unix, magically the guy who sold it to me knew what I meant).
I remember trying to learn how to install things like the packages or software I wanted and being told if there isn't an .rpm then you have to try "compiling" it.
Naively, my world view was that there was a structured process for everything - the steps for compiling something would be the same for everything, one could simply learn those steps.
In my mind I imagined it was as simple as typing "make" and an install wizard would appear in a terminal.
When it wasn't that, I would go onto IRC channels and naively ask "how do I compile things". People tried to help and I guess they thought I was an adult with the comprehension of a child so people got pretty frustrated.
Makes me laugh to think of how structured I thought the world was; thinking there was a uniform and consistent way to compile software.
Even as I sit here with experience as a software engineer, compiling someone's random github project can be mind bending - especially with some of the objectively simpler yet also more complicated methods of producing binaries from within docker containers tailored to compilation.
Loved your story, I initially learned `./configure && make && make install` under similar pretenses :p
Maybe Nix/Guix will make this a reality some day. Nix seems closer, with Flakes (which I haven't used, but think they're kinda like docker entry points, standardized package metadata related to specific package stages or capabilities?) and comma (a project which uses nix-index to make compiling and running a package as easy as ', firefox' even if it hasn't been downloaded or installed)
Loved your story, I learned `./configure && make && make install` under similar pretenses.
Maybe Nix/Guix can bring us closer to that fanciful reality. I haven't used Nix, but have been really impressed with I'm hearing about festures like Flakes, and particularly Nix Comma, which uses nix-index to make downloading, compiling, and running (without installing) a package as easy as `, firefox`.
> In logic, equivocation ('calling two different things by the same name') is an informal fallacy resulting from the use of a particular word/expression in multiple senses within an argument.
...and that is also the OP's error. I am not calling two differing things by the same word, I am saying that in this technology space, "building software" has a specific meaning that has been convention for 40 years or more. I have never heard a programmer refer to programming, or software engineering, as "building software." It is confusing. Building software means "compiling from source," and that is what it has always meant. And the semantics here are pretty important, as the OP is really talking about writing software and not constructing software from source code. Writing software is composition. It is not building anything until what is written is compiled.
I encounter people in this industry all the time who so confidently assert their way is best. This manifests itself in code reviews that insist on their way.
I have a mind to forward this article to them when I encounter them, but I don't think it would be useful and probably would be counterproductive. They would just be dismissive or offended.
>But also I've met and read some truly brilliant programmers and can't help but think they might know more than me.
I've seen a lot and done a lot in my over 20 years of building stuff. I like to think that I know some things, but I also am aware the the amount of stuff I don't know is far greater than what I do know. When I'm offering my input, I like to state it as "things I've seen in the past" vs. "what I know".
You start with a small thing that mostly works, then throw away what isn't good and add what is missing. In this process, you learn more, so it is iterative.
The main reason projects fail is not technological. The real killers are lack of analysis and lack of communication. Both are a lot easyer with 1 enthousiast doing the whole project.