What is “engineering for software?”(github.com)
github.com
What is “engineering for software?”
https://github.com/readme/guides/engineering-for-software
10 comments
I don't think we'd call statues modern and high tech.
Note that nobody claimed that they were modern or high tech, but that they were engineered! The article claims how our society is modern and high tech because we are finally engineering stuff in the last few hundred years (where we instead just ran into mechanical and construction contraptions by accident previously?).
I disagree by giving examples of engineering feats from a few thousand years ago.
Btw, for "statues", I was thinking of things like the Great Sphinx of Giza or Colossus of Rhodes (Colossus was of comparable height to the Statue of Liberty).
I disagree by giving examples of engineering feats from a few thousand years ago.
Btw, for "statues", I was thinking of things like the Great Sphinx of Giza or Colossus of Rhodes (Colossus was of comparable height to the Statue of Liberty).
I understand. I think Dave's conclusion is incorrect as well, but I think he means that most of today's progress in almost every area of life is the result of sustained engineering efforts over the last two hundred years, rather than "there was no cool engineering before 200 years ago".
The man standing on the shoulder of the giant claim he's statue is different than the giant who is standing on the mountain peak, etc. etc.
> 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.
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.
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.
> The described process is not only already implemented by everybody, there is simply no other way to do it even if you tried.
Disagree with all of this.
Disagree with all of this.
There's the intent behind it. Some systems expect you to do get right first time, but often doesn't. Others expect it to be wrong first time.
Those are two distinct approaches used in engineering.
I adore the true v1 prototype, often it's translating human needs into code that is tricky not the programming aspect -- writing an absolutely egregious program in a few hours to just confirm "so you want X to do Y like this?"
The trap is when that horror code isn't immediately binned but becomes the cut-corner foundation for even more spaghetti.
The trap is when that horror code isn't immediately binned but becomes the cut-corner foundation for even more spaghetti.
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.
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.
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.
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.
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.
I used to joke that we couldn't call ourselves Software Engineers without professional liability/E&O insurance, until I got a contract that required I hold exactly that and I learned it just costs $100/mo or so.
Guess and check is not engineering. That's what the author describes.
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 disproven.
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.
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.
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.
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 removes 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.
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 disproven.
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.
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.
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.
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 removes 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.
> Engineering is also not normally scientific investigation
People often confuse scientific investigation with logical reasoning. Software Engineers do the latter more often than the former, but they do perform the former. We literally have environments called "Test" and verifications called "tests". I find it hard to believe there's no relation.
> A hypothesis is not something to be confirmed, it is something to be disproven.
That is incorrect. The definition is available.
Hypothesis: a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.
> That's an engineering discussion
Yes and those discussions result in "hypotheses".
> Other disciplines have centuries of accumulated knowledge and modeling to fall back on.
While there are few software development papers, there is some progress. Mostly we each rely on our own experiences and the experiences of others (reading a bunch helps).
People often confuse scientific investigation with logical reasoning. Software Engineers do the latter more often than the former, but they do perform the former. We literally have environments called "Test" and verifications called "tests". I find it hard to believe there's no relation.
> A hypothesis is not something to be confirmed, it is something to be disproven.
That is incorrect. The definition is available.
Hypothesis: a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.
> That's an engineering discussion
Yes and those discussions result in "hypotheses".
> Other disciplines have centuries of accumulated knowledge and modeling to fall back on.
While there are few software development papers, there is some progress. Mostly we each rely on our own experiences and the experiences of others (reading a bunch helps).
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.
I think you just have an overinflated sense of what non-software engineers do.
Dang. Spot on.
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.
Engineering, or science for that matter, doesn't include all the values that individually or collectively motivate human beings to do anything.
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.
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.
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).
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.
Engineering, or science for that matter, doesn't include all the values that individually or collectively motivate human beings to do anything.
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.
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.
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).
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.
Civil, electronic, chemical, and structural engineers have entered the chat.
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 :).
Solved by Margaret Hamilton. http://htius.com/ https://en.wikipedia.org/wiki/Universal_Systems_Language
Cf. "System Design from Provably Correct Constructs" https://archive.org/details/systemdesignfrom00mart
Cf. "System Design from Provably Correct Constructs" https://archive.org/details/systemdesignfrom00mart
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: https://en.m.wikipedia.org/wiki/Continuous_delivery
> 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.
So constructing those marvellous cathedrals, pyramids, statues, water irigation systems etc from a thousand or few years ago are not engineering?
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.