You get buy-in from a co-worker for a cutting-edge, poorly documented, sexy but controversial technical approach by promising to do the programming yourself. Co-worker doesn't raise the kind of objections he'd normally raise if it were his project and his problem, because he doesn't want to tell you how to do your own job ("bait"). Then, when it becomes impossible to meet the deadline, you convince management that you're badly needed in a different area, so they assign your coworker to "finish" off the project, except now he has to work within the straightjacket he always suspected you were creating for yourself ("switch"). You move on to a new and interesting technology.
Some call them "Bait and Switch Developers", but in the industry, they're usually just called "Enterprise Architects."
If you're in a design meeting throwing out a bunch of great ideas while helping others understand why their ideas won't work, and you can't spot the Asshole, then chances are...
Indeed, especially in the long run when the others find out the hard way that you were right. The most interesting thing I read in the Antipatterns book was the author's claim that only 1/5 of programmers "get" abstraction and therefore "democratic" project management processes tend to result in very poor architectures.
Fireman Development (FD) - You are constantly in crisis mode and thus are only motivated to do something when someone sends you an email containing the words "CRITICAL". And yes, it has to be in all caps.
FD also has an effect on other projects. We just released not one, but two new device platforms for our software. There are other, interesting projects on the docket, but it's rare to get more than one day of interrupted work on them before getting another "ZOMG it's broken!" emails about the other projects.
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!
An interesting meta-pattern appeared in my thoughts when I combined GPD, DFD, WAD, IAD, CYAE, and DBD. It's acronym is FDD, which stands for Fear Driven Development.
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.
As an aside, it's cute when Americans say "drop an F-bomb". Swearing simply isn't a big deal in the rest of the world. Go work on a trading floor at an investment bank, an "F-bomb" just just how they say hello...
I was greeted with "G'day you fuckin' long streak of pelican shit" just this morning. I'm not in the least bit offended, far from it - it's how I know my world is in order.
I bet you don't swear at people who cook your food or at future employers do you? If not it is kind of a big deal as it still represents disrespect and doesn't belong in context where courtesy is required. Just in normal context swearing might be acceptable (as is here in America such as talking with friends, coworkers, etc).
I don't know if the stigma is true but the UK and Australia are usually seen has having completely different levels of swearing than here in the US where we are usually limited to fuck, shit, damn, and variants on ass where the severity of that list goes from high to low.
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.
Now that you mention it, American don't get swearing. I don't like hearing them swear either. Americans swearing never sound cheeky, charming, witty, good humoured, playful or anything like that.
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 thought of Australia, but it seemed not worth mentioning, mate. Even with Australia, the UK is just 1.3% of the world's population. That's hardly representative.
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.
Don't forget Shininess Driven Development (SDD) - Driven by the need to use the newest, shiniest language/framework/library available, leading to a disastrous mishmash of inappropriate technologies and half-implemented pipe dreams.
It's December and no mention of Christmas Driven Design (CDD)?
Write your system how you wished it worked and fitted together, regardless of whether your wish of it somehow working comes true or not when you run it.
My personal favorite not mentioned in the article is HDD (Hate Driven Development) When the only force accelerating progress on a project is your pure hate for everything the project represents.
Your guess is exactly right, to get the project over with. Though I had thought about leaving several times, the other projects I've worked on are not so bad. Plus the company is fantastic.
In that case, it's not exactly 'hate'. You seem to want to stick with your company because the value of the company as a whole is greater than greater than the opportunity cost of leaving it. You hate a given project, but you want to get it over with because there is a better project (possibly?) waiting for you after you're done.
In that case, it might be called 'Hope Driven Development' as your hope of getting good/not-bad projects exceeds the opportunity cost of leaving the company, and thus accelerates your development.
You get buy-in from a co-worker for a cutting-edge, poorly documented, sexy but controversial technical approach by promising to do the programming yourself. Co-worker doesn't raise the kind of objections he'd normally raise if it were his project and his problem, because he doesn't want to tell you how to do your own job ("bait"). Then, when it becomes impossible to meet the deadline, you convince management that you're badly needed in a different area, so they assign your coworker to "finish" off the project, except now he has to work within the straightjacket he always suspected you were creating for yourself ("switch"). You move on to a new and interesting technology.
Some call them "Bait and Switch Developers", but in the industry, they're usually just called "Enterprise Architects."