I recently had to give up trying to convince a coworker that the observer pattern was useful, because he refused to budge from the position that it made code harder to read as it was not "all in one place". Naturally as a stubbornly helpful person it took several hours over a couple weeks before I reached the point of surrender. Meanwhile there are a number of related decisions he's inflicting on the codebase that no one else would make, but find it easier to accept than resist, and which are ultimately unsustainable/ungeneralizable. If he left the team tomorrow the rest of the team would slowly revert these decisions. In the meantime, he's kind of just randomizing the code.
Not really a definition, but there's an example for you.
I once came in to work on a Monday to find a 200 email thread from a clique of idiot coworkers who had been feverishly working on a bug over the weekend, only to discover that our locks were fundamentally flawed, though that was at email 50. Around email 52, someone who actually knows how to use a RW lock (and has written research papers on lockless data structures) says, "no, they are fine, you're just doing it wrong, see [link]". The rest of the 150 emails were the idiots talking among themselves learning how locks work, and convincing themselves they now knew how to "work around" the bug (i.e. use the lock correctly).
This is not a thread about idiots, and actually these guys were trying their hardest to be conscientious employees... It was just a noisy and stupid way for several people who should have known better to learn how to do a simple and fundamental part of their job. (The one who falsely diagnosed the bad locking code was a 15 year veteran "senior" engineer. <scoffs>)
Not really a definition, but there's an example for you.