Part of this is because many systems are evolving, because business needs have human inputs and are not always "logical." At the edges where this human interaction happens, we expand the domain of programming to that of human psychology. There definitely are empirical claims we can make human-computer interfaces, but it begins to get a bit messy.
To be clear, I am personally interested in becoming more rigorous about empirically justifying claims I make about the code I write. But I’m also interested in code because many of the problems it attempts to solve map the very complexity of the real world. In many ways, abstraction is a properly philosophical exercise, and I think it’s impossible to separate a pure engineering discipline from this broader context.
Programming is multi-disciplinary, and I think that’s a strength.
We also have a multiplicity of building materials, tools, fabrication processes, etc. What's the standard way to make a steel object? Do you cast, forge, stamp, mill, sinter, roll, weld? I would expect engineering as a discipline to have more solid arguments for choosing which (combination) of those processes to use for a particular task than what is typically thrown around in discussions about choosing a programming language or paradigm.
The problem is that in many projects, especially small web-dev or simple automation projects, you simply don't know if they're going to be profitable. The margins are huge, since the upfront development cost is almost constant, you might lose $50,000, or you might make $500,000, or anything in-between, but you just don't really know beforehand. So obviously in this situation you want to become at least somewhat profitable as fast as possible, and then think about "doing things right" later. Is this horrible practice? Sure. But it's also the most logical thing to do here, because "doing things right" at the start is simply a huge risk that only pays off if you're successful anyway. And people would rather minimize losses than maximize gains.
On the other hand more traditional engineering tasks tend to require big up-front investments anyway, and "failing is not an option". I mean it really kind of isn't, if you need more money and/or more time you'll get that much more often here because the initial investment was so big already. So doing things right from the start makes complete sense.
> The thing is that the overhead for this process really only makes sense at Google scale.
The software industry is far larger than Google. If we want to claim that software is a discipline of engineering, we all need to have access to that kind of reference data, rather than trying to feel our way around in the dark in comment threads about blog posts about somebody's personal experiences.
I won't go so far as to say there's no such thing as software engineering -- a number of people working for companies with large budgets have well earned that title, I'm sure -- but the extent to which the term is traded like currency in our industry is disrespectful to the discipline.
> So you just assume that if you can get the job done in a way that satisfies the customer, it'll be wildly profitable, and the primary factor to optimize for is developer time.
The fetishization of developer time is one of the problems slowing the maturation of our industry. It ignores end-user time, it ignores management time; it often focuses solely on the initial development time of a project and ignores entirely the ongoing maintenance time for a project.
How many codebases are there out there that are gigantic balls of mud? How much developer time has been wasted on trying to maintain or refactor those codebases? How many really dumb security issues have negatively impacted companies or end users? How many comments has tptacek left on one little forum in one musty corner of the internet over the years trying to explain cryptographic and security-related best practices to an infinite legion of under-trained developers?
How many people have lost their lives to software defects? Not even the really tricky CS stuff, I mean the kind of defects that any other engineering discipline uses as case studies in their introductory courses.
Which case study would you choose for our Galloping Gertie?
Certainly software has done an incalculable amount of good in the world, and its impact is far and away net positive.
But while software has been busy "eating the world", it has rarely paused to also consider the cost and damage it has wrought and whether there are practices that could be standardized to reduce those negative effects. So I disagree wholeheartedly that we're not yet at the point that these things are important. Depending on who you ask, computer programming is between 60 and 180 years old. That's well long enough for us to begin asking questions like, "what data do we have to support this approach or that approach?"
There is still plenty of room for experimentation and research. There is still plenty of room for hobbyists and tinkerers. This isn't an exclusive-or thing.
As much as I really do appreciate blog posts like this one, and the discussion they tend to generate, and especially that there's a new one to read every single day (he said, wryly), I can't help but see every one of them as another indicator of the immaturity of our profession.