Morphic Resonance
-
I found this little gem a few days ago during an unofficial code review (that I shouldn't be doing, but I felt like I had to anyway in order to understand what we're doing). Verbatim:
CREATE procedure [dbo].[pr_delay] @tempo char(8)
as
waitfor delay @tempoI'm pretty sure most of us have seen things like this a few dozen times already. Some WTF's are actually quite commonplace wherever you have clueless people. Well, having recently finished reading Y: The Last Man, I came up with an hypothesis to explain why we (still) keep seeing things like DoNothing(), ReturnTrue(), YesNo enumerations, etc.
@Pseudo Science said:
In layman terms, the theory proposes that any form looks always alike because it "remembers" its form through repetition and that any new forms having similar characteristics will "use" the pattern of similar forms already existing as guide for its appearance.
(...)
This is a feedback mechanism between the field and the corresponding forms of morphic units. The greater the degree of similarity, the greater the resonance, leading to habituation or persistence of particular forms. So, the existence of a morphic field makes the existence of a new similar form easier.WTF'ery reinforces itself. Whenever someone enumerates the whole set of integers, soft-codes all the queries of an app into a table, or tries to double- encrypt something with Base64/ROT13, the chances that someone else might do just that too increase.
On hindsight, I think things worked exactly like that in most of my previous jobs. Anyone else feel like that too?
-
Not sure about morphic resonance, but it's definitely the case that crap code induces more crap code. Partly, this is because there is pressure to maintain the 'style' of existing code when expanding an application. For example, I recently worked on a database where the original tables used an integer datatype for dates (total WTF), and so all new tables would folllow that convention. In cases like this, I'd hope to put in a comment somewhere saying "I didn't want to do it like this, but convention forces me". Also, if you have senior muppets in the team, then the junior guys will learn muppetry from them if they don't know better.So I think this effect is by err induction, rather than by 'resonance'.
-
Don't forget online examples. Novice devs will copy-paste these into production code because noone told them that there is a vast difference between the barely functional example they found online and how things should work in a professional app. Then after a while they'll become profficient and start writting simple examples for other people. And the cycle then begins anew.
-
[quote user="Renan "C#" Sousa"]... or tries to double- encrypt something with Base64/ROT13, the chances that someone else might do just that too increase.[/quote]
Yeah, I have a vendor that is insisting that when we send them a file we must first PGP encrypt it, then send if via SFTP over a VPN connection...
Maybe they read a shitty article about security, maybe they are just paranoid. </shrug>
-
@vr602 said:
Also, if you have senior muppets in the team, then the junior guys will learn muppetry from them if they don't know better.
Yeah, this is what happened in my first job once I'd graduated. Most of the code at that place was WTF-worthy, and I was quite happy to participate in some of it because I didn't know any better. (Admittedly, most of the WTFs were about things other than code, i.e. version control, change management, building packages etc - the kind of things you don't generally get taught about at uni. Or at least, I didn't).
And things did improve over time, partly due to my reading websites such as this and partly due to gaining a couple of more experienced people who knew about best practices!
But then, if a company's recruitment policy is basically "Only recruit graduates because experienced developers are too expensive" you can't really expect much!
