Dogmatic coding standards - Page 1
Forum section: electronics / general

author: paulca
author_rank: Super Contributor
timestamp: August 22, 2019, 07:21:03 pm
content: There are coding standards and there are coding standards, but when someone enforces a static analyser and refuses to allow reconfiguration of it or exceptions to it... it can get very annoying. Today I had an argument with my dev lead over Java final parameters.Java final parameters is an add on to the language which was only added under duress after people demanded it. Simply because they have virtually zero functional effect on the codes operation and do not make it more secure or more robust. They are almost pointless. Sure they have uses, but in most cases they are a wet paper bag.To summarise, in Java ALL method parameters are pass by value (technically either a pointer or a primitive). No method parameters can be made "constant" or read-only by any kind of qualifier. All the "final" keyword does is stops you reassigning a parameter to reference another variable.This is what proponents of "final parameters" insist it helps prevent.public boolean isOldEnough( Date dateOfBirth, int minAgeYears ) {dateOfBirth = addYears( dateOfBirth, minAgeYears );return isBefore( dateOfBirth, new Date() );}So that code works fine. No real problem with it. However later is some work ticket comes along and says, "Log the date of birth while determining age." and a dumb programmer does this:public boolean isOldEnough( Date dateOfBirth, int minAgeYears ) {dateOfBirth = addYears( dateOfBirth, minAgeYears );log.info("The persons date of birth is "+dateOfBirth);return isBefore( dateOfBirth, new Date() );}Then it doesn't do what they think it does. Basically as the first programmer reassigned the parameter to do his calculation it has become missleading and the code doesn't act as the second programmer expects.The second programmer is dumb, sorry.The reason this annoyed me is that we are dealing with a functional programming framework called "Spark" and you work with "Datasets". Datasets are immutable. They cannot be changed and all operations on them create a new dataset. Linearity is important, so the pattern is normally.Dataset<Stuff> dataset = getData();dataset = dataset.doStuff();dataset = dataset.doOtherStuff();dataset.save();When this is placed into a method and the static code analyser whines that "All parameters should be qualified as final." It causes a far, far worse problem.public Dataset<Stuff> processDataset( final Dataset<Stuff> dataset ) {dataset = dataset.doStuff();dataset = dataset.doOtherStuff();return dataset;Won't compile. So the programmer is then forced to do this:public void processDataset( final Dataset<Stuff> dataset ) {Dataset<Stuff> someOtherDataset = dataset.doStuff();someOtherDataset = someOtherDataset.doStuff();return someOtherDataset;So when our little dumb programmer comes along and does this:public void processDataset( final Dataset<Stuff> dataset ) {Dataset<Stuff> someOtherDataset = dataset.doStuff();someOtherDataset = someOtherDataset.doStuff();someOtherDataset = dataset.doStuffWeForgotTo();return someOtherDataset;BOOM! It will compile, it will run, but it will not do what the developer thinks it will.It also leads down the path to this:public void processDataset( final Dataset<Stuff> dataset ) {Dataset<Stuff> someOtherDataset = dataset.doStuff();Dataset<Stuff> myDataset = someOtherDataset.doStuff();Dataset<Stuff> myOtherDataset = myDataset.doStuffWeForgotTo();return myOtherDataset;Leaving things very confusing as to which dataset is the actual dataset. There can only be ONE. Everytime you make a new dataset of the old one disappears. In the example where our dumb programmer re-used "dataset" again, the Spark framework will cock it's head and decide to go back to the start of the application (or the last persistance) and recalculate the dataset again. When you are processing 10Tb of data and run can take 12 hours, this is less than ideal!In my view this is a perfect candidate for absolutely NOT having a final parameter as not having the final parameter declares that you are expected to reassign this variable. It keeps things simple, it helps guide, if not enforce linearity.But my main hate is that there is virtual no reasoning behind it other than "It's the default settings for the static analyser and I want to be able to say to management that we are 100% in compliance with it."I came close to saying, "Well, if you trust it more than me, get it to write the code for you as it knows better."</rant>

author: amyk
author_rank: Super Contributor
timestamp: August 23, 2019, 12:36:02 am
content: I've seen far worse, mostly perversions of control flow caused by a "no goto" rule.Your example might actually have been the same reason I once came upon a bunch of code written this way:Code:void somefunc(Foo _param1, Bar _param2) {Foo param1 = _param1;Bar param2 = _param2;...}Every single function in that codebase was like this. All parameters had an underscore prefix, were assigned to local variables right at the beginning of the function, and the _prefixed versions were not used again after that. Looking back, it now makes sense that either someone was taught to never modify the parameters, and/or a stupid rule was put in place that prevented it, so everyone naturally came up with an equally stupid workaround.QuoteThat is also a dogmatic problem.

author: sleemanj
author_rank: Super Contributor
timestamp: August 23, 2019, 01:04:00 am
content: Code:public void processDataset( final Dataset<Stuff> dataset ) {Dataset<Stuff> someOtherDataset = dataset.doStuff();Dataset<Stuff> myDataset = someOtherDataset.doOtherStuff();Dataset<Stuff> myOtherDataset = myDataset.doStuffWeForgotTo();return myOtherDataset;...Code:public void processDataset( final Dataset<Stuff> dataset ) {return dataset.doStuff().doOtherStuff().doStuffWeForgotTo();}mmm, chaining goodness.

author: Brumby
author_rank: Unknown
timestamp: August 23, 2019, 01:29:04 am
content: Quote from: blueskull on August 23, 2019, 12:57:08 amAutomatically generated by the compiler according to some undefined but set criteria.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 23, 2019, 01:40:26 am
content: Dogmatic rules are important: they allow small, shortsighted minds to produce something possibly useful.You know the saying"Give them enough rope, and they'll hang themselves"?That is what a most people do. We just aren't very wise at all, just apes mostly grasping for the nearest fruit we can reach.We tend to only learn when the fruit turns out to be ouchy, and hurts us.If we always hand off the fruit to someone else to try and eat, we just don't care if they are healthy or safe, as long as they look good on the surface and the people we hand them off to do not immediately slap us.Talk to any true master of their field, be it arts or technology, and they'll tell you you need to learn the rules first, so you know when and how to break the rules.Most people never reach that, but the dogmatic rules allow them to play/participate nevertheless.

author: blacksheeplogic
author_rank: Frequent Contributor
timestamp: August 23, 2019, 02:47:21 am
content: I prefer parameters to remain intact in the first place which avoids the problem.

author: xrunner
author_rank: Super Contributor
timestamp: August 23, 2019, 03:40:25 am
content: I love this-Quote from: Nominal Animal on August 23, 2019, 01:40:26 am

author: paulca
author_rank: Super Contributor
timestamp: August 23, 2019, 07:07:48 am
content: Quote from: Nominal Animal on August 23, 2019, 01:40:26 amWhile I agree to an extent, the dogmatic rules have to make sense for your theory to be valid.For example one I do always enforce with gusto is using braces {} anywhere they are appropriate.if( stuff() )doAThing();Will not pass a code review by me. Yes it's valid syntax, but I have seen far, far too many times when someone else comes along later (might even have been me once upon a time) and do this.if( stuff() )doAThing();doAnotherThing();In the case I was reflecting on however the dogmatic rules have little justification and leave open a much worse problem. In my contrived and brief examples it might not seem likely for even a dumb programmer to make the mistake, but often there are 20 lines in a method and only 2 or 3 reference a dataset. It is actually quite easy for a programmer in a hurry to miss one of them and accidentally reference the parameter again instead of the already actioned-upon dataset creating a nasty, hard to find bug.There are also what I call cross-language dogma which are even worse. For example in a lot of languages this:if ( thisThing = "thisThing" ) {}Creates a next to implossible to find bug, when you means ==. In those languages an assignment always returns true, or always returns the boolean evaluation of the result of the assignment.The solution is to place the constant operand on the left which means if you accidentally use = instead of == you get a compiler error. This is valid protectional coding style.However in Java assignment directly in a boolean expression produces a compiler error. Yet I have worked in places that insist on applying the standards they got for C or C++ to Java dogmatically. and insisting on placing the constant on the left.

author: paulca
author_rank: Super Contributor
timestamp: August 23, 2019, 07:10:19 am
content: Quote from: sleemanj on August 23, 2019, 01:04:00 amYes, indeed, this does happen. In fact the whole flow upon the dataset is precalculated entirely before it is executed (called DAG), so in the framework it pretty much ends up with what you wrote.But these were contrived, short examples. Often the flow is:... do something to the dataset.... calculate and decide on something else.... do something else with the dataset.... calculate and decide on something else.

author: paulca
author_rank: Super Contributor
timestamp: August 23, 2019, 07:12:00 am
content: Quote from: amyk on August 23, 2019, 12:36:02 amWhile I agree, in this case it has advantages. Spark is a "Big Data" highly distributed, concurrent framework for processing on hundreds or thousands of nodes. Making data immutable and using functional programming makes things so, so, much more simple and robust. Migrating state is the curse of concurrency.

author: RoGeorge
author_rank: Super Contributor
timestamp: August 23, 2019, 07:58:12 am
content: My guess is many of the dogmatic programming practices have their roots herehttps://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_CodeThe rationale for each rule is explained in the attached pdf. They make sense in the context of JPL/NASA safety critical code. However, depending on the final goal and available resources, same rules might be nonsense.When annoyed about rules at the office, before getting confrontational ask why and how a certain rule helps. Also, read this again:Quote from: Nominal Animal on August 23, 2019, 01:40:26 am

author: paulca
author_rank: Super Contributor
timestamp: August 23, 2019, 08:47:58 am
content: Quote from: RoGeorge on August 23, 2019, 07:58:12 amI'd suggest that these are highly C-centric and in a lot of cases the use of the word "avoid" will be coming "never" in some dev-leads minds.I can think of things you simply cannot achieve without breaking some of those rules. Things such as callbacks which need function pointers in most platforms. Navigating a tree structure without recursion... I'd need to scratch my head for a while, but unless you flatten the tree first (which requires recursion) I'm not sure how you would do it. Depends on the underlying structure of the tree in memory I suppose.

author: nfmax
author_rank: Super Contributor
timestamp: August 23, 2019, 10:15:14 am
content: Navigating a tree structure without recursion? Ahem!https://lists.w3.org/Archives/Public/www-dom/1998OctDec/0218.html

author: paulca
author_rank: Super Contributor
timestamp: August 23, 2019, 10:31:56 am
content: Quote from: nfmax on August 23, 2019, 10:15:14 amOf course. I forgot. What can be done iteratively can be done recursively. So it stands to reason what can be done recursively can be done iteratively.On a side node DOM is one the slowest most memory hungry thing I have every seen in Java. The DOMParser took 15 minutes to parse a 1Mb XML file (TV guide listing). SAXParser did it in 15 seconds.

author: amyk
author_rank: Super Contributor
timestamp: August 23, 2019, 12:01:51 pm
content: Quote from: nfmax on August 23, 2019, 10:15:14 amI believe that's known as the "4-way" algorithm and is a semi-common interview question, but it requires having parent pointers. There's a "3-way" (also a semi-common question) which doesn't require parent pointers but relies on being able to modify the tree.

author: SparkyFX
author_rank: Frequent Contributor
timestamp: August 23, 2019, 01:27:06 pm
content: Quote from: blueskull on August 23, 2019, 12:57:08 amThe title of the topic is "Dogmatic coding standards"... what else do you expect? All boxes are ticked correctly!I mean i completely agree, some of these standards are trying to predict how dumb the dumbest person will be that comes across your code, unfortunately there is no lower boundary, which makes such rules the plaything of people to have useless arguments with technical appearance. OTOH some form of rules always need to apply, but a post here will not change that or prevent new standards like these coming up next week.

author: paulca
author_rank: Super Contributor
timestamp: August 23, 2019, 01:42:48 pm
content: Quote from: blueskull on August 23, 2019, 12:57:08 amOFFS. Pedantry award of the week!

author: paulca
author_rank: Super Contributor
timestamp: August 23, 2019, 01:51:30 pm
content: Quote from: RoGeorge on August 23, 2019, 07:58:12 amI was think about this last night while watching one of Dave's videos. The 2 minute tear down had a bit of heat sink bolted to a mosfet but was able to move. Dave proceeded to show how you would test this by attaching this to an accelerometer and (presumably) putting it on an exercise jig or vibration plate and subjecting it to abuse until it breaks so you can characterise it's robustness.Of course while your company is wasting thousands of dollars doing this the Chinese have already cornered the market because a device that sells to the general public for $3.99 ... nobody will care if it breaks after 10 years because you bounced it off the carpet one too many times.On the flip side if you were putting that into a Mars rover and wanted to absolutely prove before launch it could survive all that Nasa said they would through at it, then... it's probably worth spending $10k doing it. Of course this is why the PSU that Nasa buy costs then $190,000 each!The same applies for software and I have seen people waste weeks/months writing a fully 100% test coverage, frameworked death star to create a simple utility that nobody will ever care about if it blows up once in a while. I have seen people design "extensiblity" into applications, wasting months when there never was any requirement to do so and from any sensible persons point of view there never will be.We need to model people's legs.Programmer creates the model with 2 legs."But what about people who no legs or only 1?"Programmer spends a few days adding support for 0, 1 or 2 legs."What about people with 3 legs?""What about dogs? they have 4 legs.""There is no requirement for dogs.""But there might be. Let's not make it hard to make that change later."Weeks pass..... and now it supports, dogs, cats, horses with any number of legs.Client calls..."Can you do birds?"

author: nfmax
author_rank: Super Contributor
timestamp: August 23, 2019, 02:00:41 pm
content: One big advantage of havingworkable, well-designed standards is that it increases the likelihood of newly-written code running correctly. Which reduces time-to-market, NRE cost, and all the other good stuff. It is worth putting effort into developing, testing, and maintaining these standards because they will pay off.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 23, 2019, 02:24:53 pm
content: The interesting keyword in the OP's post here is: 'dogmatic', which is pretty much contradictory with 'scientific'.Are some coding standards/rules partially dogmatic? IMO the answer is yes. At least partially. And it's obvious why. Humans are not machines. Neither the ones who write standards, nor the ones that are supposed to develop in compliance with them.Thing is, those standards must address the lowest common denominator, which is one of the reasons why some developers may even get offended by some of their rules. Such is life. Good developers will like reasonable rules they agree with, and often hate the rules that are targeted at the bottom-of-the-barrel developers. Obvious. Standards unfortunately can't be elitist. This wouldn't work. Thing is, no standard, however low a common denominator it targets, can really predict how bad a bad developer can be.Now many of the associated rules are common sense. Some of them are much more debatable. A reasonable approach, when it is at all possible (depending on the industry you're working in), is to adapt the rules to the context of the company and projects.Something interesting to note is that a large number of people are convinced those standards make things invariably better, others are not, but most do not bother to check out if any serious retrospective study has been conducted to prove the point. A scientific approach, in other words, as opposed to purely dogmatic.You could take a look at this for instance:https://repository.tudelft.nl/islandora/object/uuid:646de5ba-eee8-4ec8-8bbc-2c188e1847ea?collection=research

author: paulca
author_rank: Super Contributor
timestamp: August 23, 2019, 02:33:47 pm
content: I think the point should be. Follow the standards until you have a professionally justifyable reason not to. Then there should (and often is in static analysis tools) a way to annotate the instance of the violation and there add your justification.Something along the lines of:@IgnoreWarnings("unchecked") // This comes from a native library and types cannot be inferred correctlySomeGenericType<> someVariable."Checkstyle" in my case does permit these, but the developer assigned to make all the parameters final was not allow to make exceptions. This is the primary reason why I got annoyed and called it "dogmatic".Rules always have justifiable exceptions.Anyway, my plan is to present two variants of a method to the dev-lead. One with final params and within it I will hide the kind of bug that will eventually result and present the clean flowing version with a check-style exception clause and ask him which he prefers.... or if he can even see the bug.

author: Mr. Scram
author_rank: Super Contributor
timestamp: August 23, 2019, 02:37:28 pm
content: Quote from: Nominal Animal on August 23, 2019, 01:40:26 amThe problem is when people aren't clever enough to understand the purpose of a rule but clever enough to work around it. The "solution" can often be much worse than what the rule tried to prevent.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 24, 2019, 02:35:34 am
content: Quote from: paulca on August 23, 2019, 07:07:48 amThere is a reason to the saying"those who can, do; those who cannot, teach".When you allow inept people to create dogmatic rules, you get rules that hinder everyone from producing something possibly useful.This reduces the boundary of breaking such rules for anyone smart enough to recognize their negative value, to approximately zero.In software engineering, such rules invariably mean that the capable ones leave for somewhere else with more sensible rules, and those left are too inept to produce anything useful anyway: such organizations run themselves to the ground.The exception is when you have capable workers that have been emotionally bound to the organization. (I know, because I broke myself exactly this way. I really am just a burned-out husk of a man because of doing exactly this.) They can end up carrying not just the dogmatic rules, but the entire unhealthy organization, just above the extinction level, without realizing how muchharmthey are incurring in the grand scheme of things.So yeah, I was definitely only considering those dogmatic rules that help produce something useful,not the stupid ones that cause only harm. I do not consider the latter "rules", but more like "guides to self-harm", you see.If you look at my posts here and elsewhere, you'll see that I get extremely disappointed/angry when capable members suggestsuch rules (or "just go with the flow" with such rules), and have caused considerable friction and unhappiness because of that.The way to decide which one each rule is, is like RoGeorge wrote: ask. Find outwhy.In my opinion, that also applies to opinions in general: they in themselves are not that interesting (because they are in many ways similar to dogmatic rules),but the underlying reasons, the basis for those opinions, definitely are interesting.There isn't much one can learn from an opinion, or a rule, but knowing the basis or reasoning behind that opinion or rule is often extremely enlightening.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 24, 2019, 02:50:27 am
content: Quote from: Mr. Scram on August 23, 2019, 02:37:28 pmThat applies to humans and human organizations in general. My observation is that most people are just quite shitty.Douglas Adams had a beautiful passage in one of the later Hitchhiker's Guide to the Galaxy books, where Arthur Dent was flying (having missed the ground) around in the night-time English skies. A bicycle thief, finding out they couldn't steal a bicycle in some back alley, nonchalantly mangles the wheels, and goes on their way.Think about that for a moment.It is extremely typical behaviour. Yet, damaging something you can't steal, just because you couldn't steal it, is completely and utterly self-harming. Not only it damages someone elses property, but it adds to the societal pressure of catching bike thieves. If bike thieves were smart, they'd ensure that the "merchandise" is never damaged. If they get caught, they'd always have the "defense" that nothing was lost, and the owner got their property back: there would be little sense in spending any resources to catch bike thieves. It would make bike thieves' life easier.Yet, those thieves are not just harming someone elses property, they are forcing the society to respond to their actions in a way that makes life harder for the thieves too,for zero benefit to anyone, least of all the thieves themselves.My point is, that is typical and expected human behaviour. You can plan for it, though. Just design suitable dogmatic rules for them to follow. They aren't perfect, and you probably need to do like the US constitution writers did, and try and add safeguards to stop inept and power-hungry people from twisting the rules too much. As observed, this seems to work, somewhat.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 24, 2019, 02:57:06 am
content: Quote from: paulca on August 23, 2019, 02:33:47 pmThis warms my heart: this is exactly how to discover in a sensible manner, how your superiors operate. No matter what the result, it gives you enough information on their behaviour to make rational decisions about the future in that job.Furthermore, there is no "right" or "wrong" answer per se, so it is not like you're entrapping someone. It is just purely finding out how the organization wishes to operate, and whether you yourself are suited for the position that entails. I like this.(Well, truth be told, I am not an easy person, and tend to cackle with glee and an evil grin when people who disagreed with me go on and shoot their foot off as a result. But, the above is how I think I/we should operate.)

author: SparkyFX
author_rank: Frequent Contributor
timestamp: August 24, 2019, 03:59:17 am
content: Quote from: Nominal Animal on August 24, 2019, 02:50:27 amIt does not make him a bike thief, it makes him a vandal, which he might have been in the first place. Expecting wisdom from people that choose this over a real job never works out, they follow the path of least resistance.I mean technical requirements are of course real, if you want predictable behavior in code certain techniques need limitations, hence rules. But when it comes to an ever growing set of rules, sometimes the rules live longer than the problems they should solve and people interpret them wider than needed if no technical reasoning is included. Also this is often seen as overhead and no one wants to constantly rewrite the rules, because they then lose effectiveness when not treated as dogmatic.This downward spiral usually goes on until it´s not possible to work anymore and requires a change of platform of some sorts that eludes this, unfortunately it does not elude how it was created in the first place and ditches an otherwise perfectly working platform. The economy probably spends billions per year on shit like this, so that people can continue to ruin value without losing their face.One obvious way around such things would be an actual training and qualification of anyone who needs to work on some system, train the lessons learned (document them ofc) and do code reviews. Another way is to go rogue, but ensure the result works (not in safety critical applications and it ceases to do the trick when several people work on it).

author: benbradley
author_rank: Contributor
timestamp: August 24, 2019, 04:52:26 am
content: I've been doing this coding thing a while, and only in the last couple years have I upped my standards by looking into the latest versions of language standards, coding standards, proper use of post-it notes, etc.Quote from: paulca on August 23, 2019, 07:07:48 amI'm sure this looks Just Fine to a Python programmer ...That's another thing, at least one coding standard (Barr) says do not use tab characters in source files, and with good reason, as there are so many definitions/interpretations of what a tab character should do Back when a programming interface was a 25x80 character terminal, a tab did the same thing in all software/hardware, but that died with the advent of the personal computer. If you press the tab key. the IDE should insert the appropriate number of SPACES. Space characters are still (so far) used consistently throughout the computer industry.QuoteI've seen that solution in standards, but since it reverses the common way of writing and reading the comparison (and the way you would say it in English), it doesn't "feel" right. Fortunately modern C/C++ compilers warn about this very thing, assignment inside a conditional, even though it's "perfectly legal" syntax. We old codgers used to rely on a separate program, lint, to find such things.Quote

author: paulca
author_rank: Super Contributor
timestamp: August 24, 2019, 07:22:09 am
content: Quote from: benbradley on August 24, 2019, 04:52:26 amAh, yes the tab vs. spaces thing.The whole point of tabs is that the are variable. The thing is it's the developer at his IDE who decides what the tabs do. They all have a "tab stop" or "tab width" setting. People seem to completely blank this, so when they open it on a server and the default tab-stop for VIM is 8 characters they throw their hands in the air and say it makes the code hard to read.:set tabstop=2And when you later decide you don't like that.:set tabstop=4Simples.Now when you use 4 spaces and later a new dev leads says the code should use 2 spaces not 4. You just better hope your IDE will allow a reformat of the entire project and you better hope nobody has any branches open because when they come to merge they will be well pissed.That and when you want to quick edit something on a server without an IDE and just use a basic text editor and you need to unindent a 20 line block. DEL, DEL, DEL, DEL, DOWN, HOME, DEL, DEL, DEL, DEL, DOWN, HOME you will be there all day.However this is one that I roll my eyes at and accept. It's not worth the argument that will go round and round and round, again and again and again.

author: paulca
author_rank: Super Contributor
timestamp: August 24, 2019, 07:23:51 am
content: Quote from: benbradley on August 24, 2019, 04:52:26 amBest way to ruin a Python programmers day.CTRL+A, Shift Tab, Shift Tab, Shift Tab, RUN!

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 24, 2019, 07:51:19 am
content: Quote from: SparkyFX on August 24, 2019, 03:59:17 amMy point was that this kind of stupidity is prevalent in humans.That is, you cannot expect an average human to behave in their own best interests, not even when they are deliberately breaking the rules!Like it or not, but that is the level of things we have to work with.Oh, I do so wish we could have a society with only self-aware rational members capable of assessing long-term effects beforehand... I just dislike the mass murder necessary to make and maintain such a society. And you'd need alien or AI rulers, because humans for sure will fuck that up in no time; they have, thus far, every single time that has been attempted. The murder count from the attempts is well in the hundreds of millions already.Quote from: SparkyFX on August 24, 2019, 03:59:17 amAgain, typical human stuff.Consider long-term software projects. Unless you rewrite significant portions of the code base every now and then, it will bit-rot.Either the tools, the underlying hardware, or the user needs change; or more often, additional features and modules are tacked on, so that the entire agglomeration becomes more and more unwieldy, harder and harder to understand and maintain, until it becomes a black box that either works or does not but that nobody can fix or maintain or develop any further.Like young men adding lights and speakers to the cars, to the point where powering them all at the same time will stall the engine, as the battery voltage sags too low. (I've seen that happen in real life, when I was young. I thought it was obvious, and obviously hilarious.)The same applies to everything humans do. Consider dog breeds, or bananas, or legal systems, for example.Quote from: SparkyFX on August 24, 2019, 03:59:17 amYou need people who know the art to participate in updating the rules; or make the rules unchanging but dogmatic and utterly simple, and keep their count low, a half-dozen to a dozen, so people can remember them.This is also the reason why sometimes it makes sense to employ someone very proficient at breaking the rules to enforce those same rules.Ethically and morally, it makes absolutely no sense to do so; but in practice, whether or not it works depends only on whether you can motivate them properly, as they have already demonstrated thecapability.