How other engineering industries deal with this phenomena? Why those approach do not work with programming? I feel silly sometimes because software development is huge industry and we don't have consensus on basics.
For example I think that strict formatting is a good thing. Since I tried to use Prettier I'm using it and similar tools everywhere and I like it. I can't do vertical alignment anymore, it eats empty lines sometimes, but that's a good compromise.
May be there should be a good compromise when it comes to "best practices"? Like "DRY" is not always best, but it's always good enough, so extract common stuff every time, even if you feel it's not worth it.
I often deal with this dilemma when writing Java with default Idea inspections. They highlight duplicated code and now I need to either disable this inspection in some way or extract the chunk of code that I don't really think should be extracted, but I just can do it and move on...
Those approaches do work with programming, but they don't make use of what makes programming different from other disciplines.
Software is usually quick to write, update and deploy. And errors usually have pretty low impact. Sure, your website may be down for a day and people will get grumpy, but you can hack together a quick fix and have it online with the push of a button.
Compare that to, say, electrical engineering, where there's often a long time between finishing a design and getting a manufactured prototype (let alone mass production.) And a fault could mean damage to equipment (or people) and the cost of having to replace everything. So you'll find that there's a lot more work done up-front and the general way of working tends to be more cautious.
There's also the idea of best practices as a form of communication. This also helps for programmers, as code that looks and acts the way you expect it is easier to follow. But code is primarily shared with other programmers. Other engineering disciplines (more) frequently need to collaborate with people from other domains. For example, a civil engineer's work could be shared with architects, government bureaucrats and construction managers, and best practices often provide a common familiar standard.
Compared to other engineering disciplines, software is a big unorganized mess. But it's also incredibly fast and cheap to make because of that.
You can destroy rockets, lethally irradiate people, fly planes upside down, or financially ruin a company because of software bugs, so avoid faults can be critical for software as well.
It is just that high-velocity low-reliability web and consumer application development is a very large niche. A lot of our best-practices are about attempting to maintain high velocity (often with questionable results), more than increasing reliability.
> It is just that high-velocity low-reliability web and consumer application development is a very large niche
And most of them have no care about the user experience of the end user at all.
Almost every piece of software I have to interact with on a daily basis is absolute garbage. Just full of frustrating bugs that makes most of my day when I'm forced to use a computer absolutely miserable. But to each of the devs it's just a small annoyance in their particular app. Not caring to the end user it's one annoyance that leads to a death by a thousand cuts.
> How other engineering industries deal with this phenomena? Why those approach do not work with programming?
A lot of engineering discipline is a way to prevent engineered works from causing unintentional injury, physical or fiscal.
Most software development is far away from physical injury. And fiscal injury from software failure is rarely assigned to any party.
There's no feedback loop to push us to standardized process to cover our asses; we'd all prefer to do things our own way. It's also pretty hard to do convincing studies to determine which methods are better. Few people are convinced by any of the studies; and there's not been a lot of company X dominates the industry because of practice Y kinds of things, like you see with say Toyota's quality practices in the 80s and 90s.
Other engineering disciplines have certification, codes and regulations for specific domains, which are enforced by law.
DRY is a perfect example though of something which in moderation is a good idea but as the article says is vulnerable to ‘inexperienced programmers who lack the ability to judge the applicability’ and if over-eagerly applied leads to over-abstraction and premature abstraction which does more harm than good.
Before regulations, other engineering disciplines have far more objective decisions and calculations than software engineering.
Consider a mechanical analogue of DRY: choosing between reusing identical parts to make design, assembly and repairs simpler or designing similar but different parts because they are worth optimizing (e.g. a whole IKEA cabinet with interchangeable screws or with short and long ones).
Unlike next month's shifting software requirements the cost and performance of this kind of alternative can be predicted easily and accurately, without involving gut feelings or authority.
Well I think the point is you can’t legislate on things like style, or at least it is pointless to do so and other disciplines don’t try to. DRY is a style guideline.
What you can legislate/codify are procedures, safety and outcomes. So for example building designs must be signed off by a structural engineer and architect, both of whom are liable if the buildings collapses and kills someone. There are standards materials must meet and for which materials can be used. Buildings must meet standards for fire protection, air flow, heat loss etc.
I’m not sure software is at the stage where we even know what to codify or what is good and what is not good.
>> inexperienced programmers who lack the ability to judge the applicability
In other words, the author knows better than you.
The author could have put forward precedent, principles, or examples. But instead he chose to make it about the people (inexperienced), not his arguments.
I think one thing the industry does not do properly is applying different practices and standards depending on context.
An retailer website is not the same as a trading platform, the same way that a house is not the same as a railway station. But we blindly try to apply the same "good practices" everywhere.
We also have another interesting phenomenon, our products can mutate in their lifetime, and our practices should follow (they often don't) an MVP can become a critical system, a small internal project can become a client-facing application, we can re-platform, re-write, etc. That's very rare in other industries.
What makes you so sure they do? Go to the hardware store and behold how many fasteners there are. Go down the rabbet hole of pipe fittings. Consider the optimal size of lumber, someday.
And then get ready for the horrors of electrical connections. Not necessarily in how many there are; the real horror is how many think there is a "one true answer" there.
You can find some solace in learning of focusing effects. But, focus isn't just getting harder for individuals. :(
In the end, other engineering areas also have lots of "it depends" situations, where often there are multiple correct answers, depending on availability, legislation, safety, physical constraints, etc.
Perhaps in software engineering people are just too quick or immature to judge.
A nit; DRY is probably not what you think it is. DRY is basically the same as SRP, framed differently. In SRP, it's totally valid to have the code twice if it has different meaning from a user pov.
The problem with definition is that it's subjective and cannot be checked automatically. So my definition was about mechanistic DRY, which is objective and checked by linter.
I think we're more like Pythagoras: some useful theory about numbers, taken way too far and became an actual religion[0] listening to the Delphic[1] Oracle[2].
[0] Tabs or spaces? Vi or emacs? Is the singularity the rapture of the nerds, with Roko's Basalisk as the devil and ${insert name here according to personal taste} as the antichrist? SOLID or move fast and break things?
Often the models and equations rely on making assumptions in order to simplify the problem (cue the joke about physicist and the spherical cow). This is one of the reasons thing are designed with tolerances and safety factors.
Software like CAD and particularly Computational Fluid Dynamics (CFD) packages can simulate the problem but at least with CFD you would typically perform other types of verification such as wind tunnel tests etc.
I'm not sure that's analogous to "best practices" like "do not repeat yourself (DRY)" or "don't use GOTO". These are little more than stylistic choices that claim to offer more maintainable code. Comparable "best practices" in other engineering fields would be along the lines of "do not chamfer/fillet until the end of modelling" (one I have heard before).
Analyzing a CAD model as you describe is more like running a compiler or type checker on code already written, which is the norm in software too, but is not within in the vein of the topic of discussion.
- I think SW needs much more creativity than other industries.
- Typically SW is not mission critical (in mission critical things, it IS pretty much regulated to uncomfortable extremes)
You could regulate it to death, and would probably have some positive impact by some metric, but you would be easily overtaken by FOSS, where for sure there will be less restrictions.
"Engineering industry" is a misnomer. Other engineering areas have the same issues with best practices we have, industries apply best practices with a great amount of success (but not to totality).
Usually, engineering creates best practices for the industries to follow.
For example I think that strict formatting is a good thing. Since I tried to use Prettier I'm using it and similar tools everywhere and I like it. I can't do vertical alignment anymore, it eats empty lines sometimes, but that's a good compromise.
May be there should be a good compromise when it comes to "best practices"? Like "DRY" is not always best, but it's always good enough, so extract common stuff every time, even if you feel it's not worth it.
I often deal with this dilemma when writing Java with default Idea inspections. They highlight duplicated code and now I need to either disable this inspection in some way or extract the chunk of code that I don't really think should be extracted, but I just can do it and move on...