Thursday 30 August 2018

* Driven Development Reprise

Thanks to the following colleagues (and in some case ex-colleagues) from ThoughtWorks for their contributions:

Giamir Buoncristiani, Rufus Raghunath, Joey Guerra, Jonny Leroy, Jean Robert D'Amore, Job Rwebembera, Andy Marks, Tobias Saltzmann, Srinivas Murty, Javier Sánchez Rois, Raimund Klein, Jim Gumbley, James Barritt, Emma Grasmeder, Gurpreet Luthra, Sowmya Krishnan, Pranathi Birudugadda, Gabriel Machado, Yasser Rachid, Kornelis Sietsma, Srikanth Venugopalan, Luciano Ramalho.

The Original Post

Back in May of this year, I posted about * Driven Development. That post started with a light hearted conversation over coffee with one of my colleagues and ended with 7 of us slaving through the alphabet to get it all finished before I would let the team sit down and order dinner. I didn't do any editing or refinement except during the discussion and I published the post that evening, without waiting for the cold (and sober) light of day.

The Post Post Discussion

As the seven of us really thoroughly enjoyed making the post and as because I wanted to publicise my blog internally to ThoughtWorks, I immediately shared the post to an internal ThoughtWorks list. This had two main effects. Firstly, it drove loads of traffic to my blog, loads more than I'd ever seen before, which was nice. Secondly, it prompted loads of our colleagues, ThoughtWorkers never being short of opinions, to propose other additions to the A to Z that I had constructed.

The Post Post Post Discussion Talk Proposal

I talk at quite a lot of conferences. At least I have talked at a few since summer 2017 - hopefully they will keep inviting me :) Most conferences allow you to submit a few different talks for consideration. I usually submit a couple of talks that I've done at previous conferences together with a couple of new ideas. If the rules allow it, i.e. if the maximum number of submissions is high enough, I like to propose something a bit more out of left field. Sometimes these left field submissions get accepted. This was how my Architectology talk was accepted originally (although it since morphed, I think, into a very serious message).

Unfulfilled Desire to Perform

I suspect that my enjoyment of presentations satisfies my unfulfilled (through lack of any real talent and material) desire to be a stand up comedian. I like to try to make the odd joke when I talk on stage (not always successfully) and I thought that the blog post, if presented as a lightning talk could play a bit like a stand up gig. The only problem was that I felt that in order for it to be accepted it would need to have a serious message. A straightforward recital of a mildly amusing blog post would never get into the conferences and, frankly, would be a rubbish talk.

A Serious Message

When we created the original post we had a single rule for acceptance. The person proposing the entry needed to have experienced the thing at some point in their career. This is fine for all the serious stuff (TDD, BDD etc) but probably less so for some of the amusing or dysfunctional things. So I started to think about what should REALLY drive your development. I can't answer that question fully during the last few minutes of a lightning talk, but my proposals promised to give at least one sensible answer. So I submitted the proposal, with a link to the blog post and a teaser about what SHOULD drive your development. Now I just have to make the slides (and work out the best answer to the question) as I've had the talk accepted at two conferences so far...

The Additional Candidates

I won't be using any of these in the conference talks (as they weren't in the original and a lightning talk has limited time) but here are the extra suggestions from my ThoughtWorks colleagues. The indented text is my annotations, everything not indented is directly quoted.


Blog Driven Development - where a developer doesn't know how to solve a problem but finds a really cool looking blog on hackernews that says they need microservices and just follows the steps listed there because it is easier and quicker and has 26 microservices supporting a simple authenticate, validate and map requirement.

Beer Driven Development 
and its corollary
Hangover Driven Development

Interestingly I think that beer driven development involves over enthusiasm for an idea / design - and hangover driven development is a harsher environment for ideas and therefor can produce better work.

I think maybe it needs a disclaimer that not actually promoting the use of alcohol to improve team performance:)

Buzz word Driven Development - Similar to resume driven development.
  • Hacker-news driven development 
  • Twitter driven development 
  • Industry Leader driven development ( where google/fb/netflix release libraries and people just follow)
These bullets came with the above indicating, I think, that they are variants of Buzz word driven development.
Bundle driven development - I remember working for an IBM partner who would sell bundles of things to clients - so, if you bought IBM product X you'd also get the IBM http server, and the IBM directory server, and a bunch of other crap. I remember using IBM MQSeries in a software tool as an in-memory queue - because they'd already paid for it...

I hear someone say Atlassian is similar? Probably unfair to put IBM and Atlassian in the same sentence, but I have cried enough over a Bamboo setup, just because the client wanted to use Confluence.
The Atlassian comment was added by somebody as a response to the original poster who mentioned IBM products.


Conference Driven Development - When you look up something you want to learn, you submit a talk proposal about it, you get accepted, you panic first but eventually you learn it and give the talk.

I have done this myself. I was told by a colleague when I first started at ThoughtWorks never to prepare any slides until a talk gets accepted for a conference. I took it further by not really doing any research about Quantum Computing until the talk got accepted (although I did cheat a bit because the subject really interested me) and when it did get accepted I properly panicked! Hopefully when I give this talk again it will be much improved.

Case Study / Press Release Driven Development - Focusing on what an ideal success story would look like for your endeavor and working backwards from there. Good to keep this focus throughout the project, not just during a one-hour session during inception ;-)
This one is closely related to README Driven Development

Console Driven Development (Mainly in JS) - When instead of writing readable tests that will clearly show the output of your code against expected put console logs everywhere, nail the bug and commit the code with the logs.

Commit Driven Development - Under the right circumstances, I find it helpful to prevent scope creep and yak shaving, which I'm susceptible sometimes.
I had never heard of this before the discussion. When I reread the discussion thread to make this post, I had forgotten what it meant. I looked it up here. I like the idea and I think I might try to do it the next time I'm writing code.


This was posted like this, no elaboration, block capitals, exactly as I've reproduced here, by a ThoughtWorks QA. I'm not sure if he was trying to tell me something.
Delete the Tests Driven Development - first you write the failing test, refactor, realize the refactoring didn't work, delete the test, deliver the feature.
I sincerely hope that none of my colleagues have been involved in this type of development!
Data Driven Development
There was no elaboration on this one and nobody followed up. I think it is like the (good) version of Metrics Driven Development where you release a small change, check to see whether you moved some needle in some direction and then take a decision as to whethe the change was "good", "bad" or "needs more data". 


Golf Driven Development - In reference to how OTC packages procurement decisions are made.
This was proposed without any elaboration but when an elaboration was asked for we discovered that this is a reference to the corporate habit, which I believe is still a thing, of inviting business acquaintances out for a round of golf (and presumably wining and dining them afterwards) to discuss products and services.


Hotfix Driven Development - Where projects just wait for failures in production, fix them, push them and call it done never to touch and refactor that demon again ;) 


Metrics Driven Development - For example, I’ve seen a (non-TW) project been run in the past where the head of support had dictated that each developer had to fix 4 defects a week on the project. 

Meeting driven development - Where a big meeting is needed to drive every decision.


Pain Driven Development - When you focus on incrementally reducing the pain that a group of customers / users are feeling. A good example is gradually reducing the most painful areas of customer support in a call center, or the highest volume of support requests a group are receiving. It's really a prioritization technique, but can be a good way to structure moving from a fully manual to a sensibly automated solution.

Press Release Driven Development - See Case Study Driven Development.

Production Issues driven development - Similar to Defect Driven Development, but more focussed towards Urgent bugs -- since there isn't any other option. Likely same as Failure driven development.


Resume Driven Development - When every technical decision is based on whether or not it’ll look good on your resume.

This was suggested by one of our North American colleagues. I had to refer him to the "C" section of the original post.
REPL-driven development - A perfectly valid choice when your language and it's toolset support it.

Responsibility-Driven Design - On a more serious note, I think the first time the *DD acronym was ever used was by Rebecca Wirfs-Brock (Responsibility-Driven Design).

README Driven Development. -This is a thing.


Type / Type First Driven Development - This is a thing.


You need a few more first letter options:

Maybe "┼▓nicode Driven Development" - where you need to somehow make changes to prove that ascii isn't sufficient for your problem?
I've reproduced this as it was written originally. When I followed the link I made the (perhaps bold) assumption that the two were related.


Voucher Driven Development - Build the entire infrastructure of your hundreds of pet projects using vouchers, student packs and free usage quotas given by the cloud computing providers.