With thanks to my colleagues - Andrew Jones Weiss, Velizar Genov, Gergo Takacs, EnterTheDragos, Robert Chow, Stuart Paton.
I had a conversation with a friend a couple of days ago about what work his team was doing. They were supposed to have done some work "in time for UAT" but they missed getting a couple of stories into the locked down UAT environment before the deadline. Thus, UAT wasn't going to cover those use cases. The next UAT wasn't due to happen for a couple of months so they changed their focus on to some different stuff.
I laughed at this and commented that this sounded like Politics Driven Development. I had never heard the term before but given the nature of the organisation my friend works in, I thought it was an apposite term for what they sometimes end up doing. That got us into discussions of what other *DDs exist.
We then set ourselves the challenge of coming up with a whole alphabet of *DDs. Some of them are serious, some of them are not, some of them we made up to get through the alphabet. Our criteria was that for something to stand it either has to be a real thing or the person suggesting it had to have experienced it at some point in their career.
Any more suggestions welcome!
AWS Driven Development - This is when your company migrates from the old server farm to AWS and all future development is constrained by the tools and services that AWS offers.
Behaviour Driven Development - this is a thing.
Bullshit Driven Development - when an influential developer blags that they understand a technology and the team goes too far down the road of relying on that technology before they realise that (a) that developer was lying and (b) the tool is not appropriate for the job. Extra points if the developer that influenced the decision leaves the company shortly after the decision was taken. Kafka is a repeat offender in this space.
Bleeding Edge Driven Development - this is when you must on NO ACCOUNT use any technology found closer to the middle of the ThoughtWorks Tech Radar than the Assess ring. If there has been a conference with this as its main subject you may still use it but only if that conference was an UnConference.
Career Driven Development - when a decision to use a language or technology is not driven by what is best for the problem at hand but by what the developer or developers want to learn to enhance their career within an organisation.
CV Driven Development - like Career Driven Development except the motivation is to enhance your CV with the intention of moving to a different job.
Domain Driven Development - this is a thing.
Developer Driven Development - This is when developers as a group decide that they want to do something interesting. So they decide that instead of using boring old Java for their Microservices that they are going to use shiny new and interesting Clojure. This could also morph into one or other of the types of CDD.
Ego Driven Development - It’s what Rockstar developers do.
Failure Driven Development - Your system has so many defects with new defects being constantly reported that you never have the bandwidth within your team to play any stories that add new value. You are sentenced to be forever jumping to the tune of the person in the business who is screaming the loudest to have their defect fixed.
Fowler Driven Development - When Martin Fowler posts a new blog post that could impact your work in progress you then make it your business to ensure that it WILL affect your work in progress. Extra points are awarded if you contact a friend you have within ThoughtWorks to ask for a clarification on the nuance of what Martin was referring to before you modify your stories.
Google Driven Development - Like AWS Driven Development except you use Kubernetes and the Google Cloud tools.
Hypothesis Driven Development - This is a thing.
HiPPO Driven Development - This is based on the HiPPO decision making process that many organisations rigidly stick to. To implement HiPPO decision making you gather a large group of people in a room to discuss the decision. The larger the better. You then discuss the thing for a long time listening to everybody's opinions, including those that will live the consequences of the decision. Then, the Highest Paid Person's Opinion (HiPPO) is aired and that is the decision taken. HDD is when the priority of features is decided purely on the seniority of the person that requested it. Actual business value is irrelevant and pointless to argue about. If the CEO requested it, it's the first thing you do.
Hype Driven Development - This is strategic decisions based on what the current "big thing" is (see also ThoughtWorks Driven Development). So if the buzz in the industry is Microservices, then the CTO will be demanding that we "should be doing Microservices" irrespective of cost of value.
IntelliJ Driven Development - when you join a new codebase the IDE tells you all the bad things about the code. AKA Alt + Enter Driven Development.
JetBrains Driven Development (see IntelliJ Driven Development)
KISS Driven Development - Let’s keep this one simple.
Kangaroo Driven Development - I’m struggling here, you may have noticed. This is when you have a weak or no product owner who has a bad time articulating upwards what is important and what isn’t. You therefore end up jumping from one priority to another never quite knowing from one week to the next what your purpose as a team really is.
Lifestyle Driven Development - As a tech lead I always think there are two kinds of decisions. Those that I care about and those that I really don’t. Some people get really exercised about the second type of decision. I’ve seen conversations over whether we should use a 2 or 3 space indent in our C# code rumble on for 3 months. Seriously. And it involved edit wars in FXCop lint rules. Any such decision, that really doesn’t matter in my view, is a lifestyle choice. Lifestyle Driven Development is when this type of Bikeshedding dominates team stand ups, team planning meetings and all team conversations. Even in the pub.
Marketing Driven Development - when a marketing campaign proves that a market exists for a new product that you haven't built yet, forcing you to build it.
MoSCoW Driven Development - this is a thing.
Negativity Driven Development - This is when your developers are so negative about the prospects of the code not falling apart that you write dozens of tests that test the edges of the edge cases that can only ever be hit when all 8 planets (and Pluto) align in such a way that frogs fall from the sky and turn into baby poodles before they hit the ground. This causes such immense scope creep that your project funding expires playing the first story and nothing ever goes live.
Optimism Driven Development - This is when you design for the happy paths only because obviously those are the only bits of your system that will ever get exercised. This is very true, until your project goes live at which point you have to run for the hills.
Politics Driven Development - Many large organisations are riven by internal politics. When you work in such an organisation you know about it. Politics can lead to some pretty illogical decision making around prioritisation of your backlog. Conversations could be something like "We think this is the most important thing but we need to keep this group happy because we need them onside to help with next year's budget approvals".
Patterns Driven Development - When one developer has recently read Design Patterns by the Gang of Four and goes through the codebase insisting that everything be refactored to closely follow some of the patterns in the book. It doesn't matter if it is an appropriate pattern for solving the problem at hand and it doesn't matter if the code being refactored is covered by solid tests that can verify the refactoring. In fact it is better if there are no tests at all so that you really have no idea if the code still behaves as expected. Patterns Driven Development is an Anti-Pattern.
QA Driven Development - This is a thing but every reference I found to it calls it Tester Driven Development but we already had stuff in T.
Resharper Driven Development (the Visual Studio version of IntelliJ Driven Development).
Retro Driven Development - This is actually a good thing. This is when you do something for two weeks, discuss how it can be improved then realise that you were doing it wrong so now you do it right. Wash and repeat.
Sales Driven Development - This is when your sales team makes a bespoke deal with a new partner assuring them that we have systems in place to support these weird business rules that they just invented on the fly. They then come and talk to the tech team and say things like "we can do this, right?" It obviously doesn't matter if we can or not because we're now committed to hastily implementing the features that we have already sold. This happens a lot in start up companies.
Stack Overflow Driven Development - It’s a thing, no really! It is! This is often characterised by code comments saying “I don’t really know what this does but here’s a link to the Stack Overflow page”.
Test Driven Development is a thing that I hope we are all familiar with.
Underwear Driven Development - This is when a team works as a distributed team and most people’s default setting is working at home. During stand up everybody is on a video link and you can tell which developers aren’t dressed yet because their video feed will be a black screen with “John’s iPhone” written on it.
Value Driven Development is a thing.
Waterfall Driven Development - We’ve all been there. Hopefully not recently. Oh dear, does last year count?
Wagile Driven Development - When you are actually doing Waterfall but the project management like to claim you are doing Agile.
XD Driven Development - I thought this was a real thing but when I Googled it I couldn’t find it. At a place I worked recently the client had a really strong UX department and their product design was heavily influenced by what the UX people did with user research and workshopping. It seemed to work pretty well, the product was really cool that we built and had good take up from the target market.
Zealot Driven Development - When somebody in your team is so vehement in their beliefs that they drive the team forward to complete the work according to their standards. This was, in fact, the method used to construct this blog post. My colleagues are now desperate to order some food having been forced to finalise our definitions before I allowed us to sit down for dinner.