My Engineering Axioms
martinrue.com
martinrue.com
Pet peeve time. It would be so great if people used the word "axiom" to mean exclusively "I need to blindly assume this is true, otherwise I do not see how can I make any progress". This article contains, I think, author's advices.
The dictionaries (and people) usually conflate "a proposition which cannot actually be proved or disproved" with "a self-evident principle"/"an established principle", which looks like a very huge confusion to me. It's like mistaking math and physics. It's like claiming Euclid's fifth axiom is self-evident, when others have already shown this was just an implicitly made decision (hence non-euclidean geometries), which cut off some very interesting, but difficult, mental models. (Quotes are from https://en.wiktionary.org/wiki/axiom)
I wouldn't protest, but I see educated people repeating this confusion over and over like a broken record.
Or is there a more precise term in English for those things?
But I agree that this list of opinions stretches the term enough that it's a distraction - these are just well-framed observations about the nature of engineering.
It would be a shame not to have a very precise term for that, so I stick to "axiom" anyway.
I think it's reasonable to wonder if its even possible.
One thing that feeds into it, and is due to the poor way we teach language, is that people think that dictionaries prescribe how we should use language. But that's not what dictionaries are.
Dictionaries are descriptive, recording how people are using language.
This is a very important distinction.
Instead of trying to remove the possibility of ambiguity from language, we should instead focus on gaining the skills to reduce ambiguity through discourse, which we are extremely bad at.
As programmer's I think we are specifically enclined to attempts of formalizing natural language into something precise and reducing it to syntax and semantics.
Yet like you say, natural language is imprecise. And the more I think about how much of a bodge the way we communicate is, the more impressed I am we can have conversations at all. All those layers of indirection, wtf?
But of course for almost every layer of indirection there is a safety net, that assures the meaning of what is said is passed on: If I mumble, my body language will help you figure out what I'm trying to say. If write gbbrsh sntce, context make you understand. And if you can't hear me, you can probably make out what I'm saying by lip reading.
Indeed, some of these are possible to falsify with experiments. For example:
> 14. A good type system is worth its weight plus some.
See e.g. what Dan Luu has written on this subject.
I would also add the following which work for me:
1. The 80-20 rule - remember that meeting 80% of the spec takes just 20% of the time and plan accordingly.
This cuts both ways. In most cases, it’s not too much work to build a prototype and ascertain whether its worthwhile to pursue further, but attaining feature completeness, even asymptotically, requires a lot more effort.
2. Be mindful of the sunk cost fallacy - it is important to identify the point of diminishing/no return and turn back immediately.
Corollary - if you think you are most likely wrong, admit to this openly, to yourself and your peers.
3. Talk the walk - If you are convinced that you have a good product/feature, don’t hesitate to push for its adoption, even in the face of inertia/resistance.
4. Remember that integrity is doing the right thing even when this may be disadvantageous to you in the short term.
Speaking of change, regarding #1. I am not clear how to reconcile (Agile's?) "embrace change" with the well-known observation that fixing a problem in a SW system seems to be more difficult later in the design-implement-test cycle. Commonly, this is addressed by making that cycle smaller, but it seems to only constrain the design space (large and consistent designs are ruled out). (There is probably a good reason why we don't build buildings using Agile, but we gather requirements first and then build it.)
Finally, I would add a rule - Don't change what works.
The distinction between "easy to delete" and "easy to replace" is subtle but important. The latter can lead you to write interfaces, proxies and factories. The former, to stateles and pure functions.
Also:
> 25. A good design is one in which you can change your mind without changing too much code.
On a tangential note, here's my take on the subject of engineering principles: https://hliyan.medium.com/elements-of-a-software-engineering...
In my own experience, "14. A good type system is worth its weight plus some." really depends.
If you are trying to make a mobile app, I agree. If you are trying to make a deep learning framework for researchers, I think the evidence is pretty clear at this point that type systems have more cost than benefit. Pytorch, Tensorflow, Jax, Keras, etc. are all far more popular than their strongly typed alternatives and I would be willing to bet this remains the case for many many years.
I mean, it should have been. >.>
They abstract to operate on a higher level of thought. I.e Business policy not networking code.
Instead write code operating at the level that best expresses the problem you're trying to solve. As if you are writing a business document to explain it. Fill in the concrete details afterwards.
If your doing invoices, solve the problem at level of invoices, transactions, percentages, addresses, tax and emails.
Best expressed as outside in
The author is writing specfically about software engineering but by by-passing the 'software' word in the title he is making a disservice to the real engineers (those professionals who have to go through a rather demanding set of requirements to be considered as such, e.g. mechanical, structural, chemical, etc).
We software developers love to be called engineers because it give us gravitas and status. But we fool ourselves and, most importantly the public, as our field is not regulated and it doesn't have a clear mandate nor ethical rules as the registered engineers.
I had to write an oath to my province to execute on that faithfully. I was working with private health records. I know lives weren’t at risk, but it took a lot of knowledge and resources to execute on that properly, and maintaining quality and privacy around those systems is genuinely very important.
I don’t call myself an engineer, but I don’t think my job is a joke either.
Middle English (denoting a designer and constructor of fortifications and weapons; formerly also as ingineer ): in early use from Old French engigneor, from medieval Latin ingeniator, from ingeniare ‘contrive, devise’, from Latin ingenium (see engine); in later use from French ingénieur or Italian ingegnere, also based on Latin ingenium, with the ending influenced by -eer.
So the evolution of the word engineer to encompass software engineering is its emergent, and I’d imagine by the middle of this century, it’s dominant, form.
Engineering is simply using knowledge & resources to develop systems or processes that solve human problems. When you're developing software to solve human problems, that is absolutely engineering.
EDIT: I think this is ok in such a young field, but we should not deceive ourselves into believing that what we have today is anything like more mature engineering fields. We should also strive to attain their levels by investing more into high quality studies and less "axioms".
I agree that software development (engineering) is a young field, and thus there's even MORE we don't know compared to many other more mature fields.
We should certainly strive to increase knowledge via high quality studies. We currently have a serious problem: There is little incentive to do useful high-quality studies. Many people in CS are in a "publish or perish" mode. Publishing ideas is what's important, while scientifically showing whether or not something is true is not required (and takes much longer than posting an untested idea). Just look at paper after paper, and then ask how many show the results of scientifically rigorous experiments. There's remarkably little about the control vs. the experimental group (as an example). There is work that does real science, and I highly praise it - we just need more of it.