A few other patterns may make appearances, depending on the organization, but the practical upshot is something a former manager of mine kept on about regarding working at large, asshole driven organizations: focus only on requirements. Do precisely what you are told to do, and precisely what you are told to do it on, and do absolutely nothing else to anything else. For developers, this involves fixing or implementing precisely what the bug ticket tells you to, and committing precisely that to the repository. For the tester, this involves testing precisely that feature or fix the ticket indicates, and not suggesting in any way that another related fix could be rolled into this one with little effort. For the project manager, this consists of having endless meetings with people to make absolutely certain the items on the task list are prioritized correctly, and dragging developers and testers into those meetings to project an image that your organization is "engineering driven".
Expect that if you violate this tenet, you will face unwanted consequences, even if things turn out well for what you were working on. It doesn't matter that you made things better for the organzation; you usurped the task-delegation authority of someone else, and it is quite possible that person was hired for that specific purpose. If you show you can self-manage, this person is now redundant, so it is in their best interest to show you can't self-manage by making sure you are scared completely shitless of ever doing so. Vague threats and social politics work well here.
But it's not that the individual wants to abide by these particular patterns; it's that they are wedged into a political canyon. They know that whatever effort they might put in to making things better will result in them being fired for insubordination as soon as someone finds out what they've done. Would they like to keep their job and deal with a horrible codebase, or would they like to lose their job and have nothing but the bitter taste of a horrible legacy codebase you can now do nothing about.
These are all symptoms; the cause I've always seen is that the staff are scared shitless, and want to make sure no one can hold them responsible for anything. It seems to me that if you get rid of that, you get rid of the catalyst behind a lot of these other problems.
It is usually taken that AU/UK have many more words and/or variations which would mean that common speech would have more possibilities to interject a curse word.
I had an American friend at Uni who used to try local swearing or idioms from time to time. "Bloody deadshit!" "Ya reckon?" Relatively tame in the context (bars) he was trialing them. He could never pull it off smoothly, it always got him funny looks. The French, Arab or even Chinese could do it. It sounded fine. Not this guy.
I wonder what makes it like this.
No wonder you ban swearing in The States.
Edit: No malice intended.
They tried a pilot for a localised version once. Never gonna work.
P.S. Actually, I wasn't too sure about Aussie speech patterns besides the usual stereotypes. Either way, with its 22e6 population, it doesn't sway the argument.
Garbage Perpetuation Development (GPD) - You can't believe how bad the existing code base is, but you're afraid to open a can of worms, so everything you add to it is written in the same style. For the rest of your life, you can say, "It was like that when I got here."
Mansion in the Quicksand Development (MQD) - The opposite of Garbage Perpetuation Development, you are so shocked by the poor quality of the existing code that you vow that you'd rather swallow razor blades that code the same way. So you write a tight beautiful refactored masterpiece that will crash as soon as the underlying database loses its integrity (later tonight).
Defer to the Framework Development (DFD) - You're not sure how to tackle quite a few critical design/architecture issues, so you convince your boss to adopt the framework du jour and decide to "let it handle it". As soon as someone needs something that the framework doesn't handle, you blame management for making such a myoptic technology decision and say that it can't be done. You keep your job and get a new boss every two years.
Not Invented Here Development (NIHD) - The opposite of Defer to the Framework Development, as soon as you discover something the the current framework can't handle, you abandon it and write all you own routines. Everything now works exactly as you want it, but with all the additional code to maintain, your backlog has just grown from 6 months to 2 years.
Whoever Screams Loudest Development (WSLD) - Just as the name implies, you work for the customer who screams the loudest. If anyone screams louder, you drop everything and work on their project.
F-Bomb Development (FBD) - Whenever everyone is screaming so loud you can't hear anything, you work on the project of the customer who drops the most F Bombs.
Start Over Development (SOD) - A critical requirement cannot be supported by the current architecture, so you decide to rewrite it. You spend 3 months designing the new architecture and then 6 months writing the new code. You never finish because you're out of business. Now you know what "critical" means.
Workaround Development (WAD) - The opposite of Start Over Development, you can make the current system do anything. You are so clever with your extra algorithms, functions, and data bases. Even with all your great variable naming and comments, six months later, you have no idea how anything works.
Code Generation Development (CGD) - You're so tired of writing the same code over and over, that you write a code generator to do it for you. What used to take a week only takes a few hours with the new tool. But you're no further ahead because 80% of your time is needed to enhance and maintain the code generator.
Infinite Prototyping Development (IPD) - Your customers and users are unable to describe or document their requirements. So you spend lots of time with them understanding their business and when you're ready, you throw together a prototype. They love it, but it needs just a few changes. You keep making changes, but it always needs more. It stays a prototype forever. When the app crashes because of security or scaling issues, you're off the hook because, "It's only a prototype."
Infinite Analysis Development (IAD) - You never have to do anything because you never have specs. Woo hoo!