While i sympathise with some of the points, the author doesn't do himself any favours by claiming things like:<p>> I argue that "engineering" is the difference between our modern, high-tech civilization (only a few centuries old, at most) and the hundreds of thousands of years of human experience that preceded it.<p>So constructing those marvellous cathedrals, pyramids, statues, water irigation systems etc from a thousand or few years ago are not engineering?<p>Just like anything else, human mind is exploring similar avenues for thousands of years, and there is no good basis to claim that we've been doing engineering for only a few hundred years.
> We need to iterate so that we can have more opportunities to learn. We need to gather feedback so that we can reflect on the results. We need to work incrementally so that we can compartmentalize the problems in front of us and explore them efficiently. We need to organize our work into a series of small, safe experiments so that we can build our knowledge up in a more productive way. We need to capture data from real world systems so that we can learn empirically what really works and what doesn't.<p>This is nothing but a collection of platitudes, blog spam. The described process is not only already implemented by everybody, there is simply no other way to do it even if you tried.
Sometimes I wonder if all these people that talk on conference stages are nothing more than self-help gurus. All of these words like "productivity", "cleaner code", "maintainable" etc. etc. are like highly optimized words for our dopamine network. They don't add any value to the domain of software engineering. I first realized this when I flipped through Uncle Bob's "highly recommended" Clean Code and almost screamed in horror at the amount of bullshit that book has been able to infect into the industry. Yes, the words sound nice, but look at the code examples. Just look at them.
As a personal anecdote: I remember being at the ESRI Developer Conference back in 2019, and one of the keynote speakers spent a good amount of time talking about whether we were software "developers" or "engineers." I'm paraphrasing a bit, but ultimately he concluded that we were engineers because we follow scientific methods, identify problems, solve them quantitatively, and create solutions within the confines of external constraints, such as the laws of physics.<p>During the Q & A, someone stood up and proposed that by his definition, authors were literary engineers, since they approach writing a novel in the same way that we approached writing code.<p>I didn't have a horse in this race, but I remember thinking about how silly it was for my company to spend hundreds of dollars to fly me out across the country so I could listen to brilliant people discuss semantics at a software conference.
Guess and check is not engineering. That's what the author describes.<p>Engineering is also not normally scientific investigation. The author uses "hypothesis" in the worst layman manner. A hypothesis is not something to be confirmed, it is something to be <i>disproven</i>.<p>No, engineering is primarily about the application of predictive knowledge and models to create and implement designs which are robust to known operating parameters and unknown model error.<p>Guessing and checking frequently (via CD) has merit. In fact in the limit you can eliminate the human in the loop if you add in some basic rule like "reduce error with each step". That's automatic optimization.<p>But if you want to talk about engineering you need to talk about constraints, predictive formula, and industry knowledge guiding design choices. If you need to serve 1M QPS, is a single sharded single node Elasticsearch instance on an MX5 large sufficient? Why or why not? That's an engineering discussion. If you need to identify the closest points to a vector in Nd space among 1B points what algorithms produce tenable runtimes? That's an engineering discussion.<p>Other disciplines have centuries of accumulated knowledge and modeling to fall back on. They don't have to guess (mostly) which metals will survive high temperatures. Or how air will flow around a given shape. We have similar knowledge that explicitly <i>removes</i> the need to guess. Again, checking is always good, but the valuable tools in an engineering toolbox massively reduce the search space before any implementation is attempted and that's the heart of engineering.
Sure if you squint from far enough away we're all "Software Engineers", except for (1) the training, (2) the reproducibility and predictability of how we work & what we build, and (3) the ethical commitment & personal responsibility. You could also call us "Software Doctors" ...in the mold of Dr. Frankenstein.
Other than the reference to SpaceX this post left the "engine" out of engineering more than I think is a viable amount of creative license.<p>Engineering, or science for that matter, doesn't include all the values that individually or collectively motivate human beings to do anything.<p>An engine can be the core component of what an airplane or rocket is, and science can help us optimize fuel type or efficiency, or make a more stable flight, but science and engineering will not lead us to decide whether to use that airplane for leisure or war. Perhaps in a perfectly technocratic society it is arguable that engineering and science are the ultimate guiding values and principles, but that is not the society or societies we live in.<p>As far as software, it seems to me its engine is the microprocessor, but much if not most software is not working in tandem with some engine on the other end, exceptions being cars, planes, 3d printers etc.<p>Rather, software is very malleable and although end users want things to work well, they also are accustomed to a steady if not daily flow of updates, which the author of this blog post has some expertise with (I would consider the development if continuous delivery an engineering endeavor).<p>All that to say is I think the author should look more deeply elsewhere than science and engineering as to the why and what to build, or ironically the epistemology, ontology, methodology and axiology will sort of just be pulled out of the air ad hoc, perhaps the least scientific way of operating.
I think one of the big distinctions between software engineering and development is objective decision making based on data and evidence versus conjecture and opinion. I’d suggest that while there are instances where software is engineered, most software is developed. I’d also submit that this is mostly driven by pragmatic reasons like maximizing benefit to cost ratios. Of course this is all conjecture but hey, I’m a Software Engineer :).
This article made more sense to me when I combined it with the Wikipedia page on Continuous Delivery, a term partially coined by this author: <a href="https://en.m.wikipedia.org/wiki/Continuous_delivery" rel="nofollow">https://en.m.wikipedia.org/wiki/Continuous_delivery</a>