Skip to content

Latest commit

 

History

History
119 lines (90 loc) · 4.69 KB

README.md

File metadata and controls

119 lines (90 loc) · 4.69 KB

Crappy Driven-Development (CDD)

Let's learn a new development practice : Crappy-Driven Development. The secret art of making yourself indispensable by writing crappy code !!!

Crappy-Driven Development

Kata

In small groups / mob :

  • Choose a code in a language you want to work with (C#, java, scala, js)
  • Your objective : Apply CDD to make the code so crappy that other groups won't be able to understand it
    • Follow the golden rules described below Crappy-Driven-Development
    • Make it in Baby steps (crappy 1 thing at a time)
  • You have 30 minutes to make as many cycles as possible :
    • Make it in mob
    • Be creative
    • The more brainfuck it is the better
    • Tests are green before and at the end of your refactoring

Mob roles

I recommend to use mobtime and configure below roles :

  • Turn Duration : 5 minutes
  • Create the 4 roles presented below

mob config

Driver

driver

  • Write the code according to the navigator's specification
  • Listen intently to the navigators instructions
  • Ask questions wherever there is a lack of clarity

Navigator

navigator

  • Dictates the code that is to be written - the 'what'
  • Clearly communicates what code to write
  • Explains 'why' they have chosen the particular solution to this problem
  • Check for syntax / type errors as the Driver drives

Scribe

scribe

  • Write down the goals of each cycle in mobtime
  • Explain why it has been decided

goals examples

Crappier

crappier

  • Anticipate what can be crappier
  • Write down ideas that emerge in his/he mind and other ideas as well

Source of inspiration

If you need some inspiration, here are some cards to pick crappy ideas.

Crappy Ideas

Review

At the end of the 30 minutes period each mob presents the new version of their code.

Clean Code principles

Map each crappy action with at least one of the Clean Code principle available here

Programmer's Brain

If you want to understand the impact (on cognition) of not using Clean Code principles in your code you should definitely read Programmer's Brain - What every programmer needs to know about cognition by Felienne Hermans.

Why reading code is important Reading unfamiliar code is hard Code smells and cognitive load Linguistic Anti-patterns Linguistic Anti-patterns in figures

Book infographic

Here is my infographic from this great book.

Programmer's Brain Infographic

Clean Code from the Cognition Point Of View

Clean Code slides

Workshop

If you want to go further, I have created a workshop in 2 parts based on the learnings from Felienne's book:

Programmer's Brain workshop

Reflect

Take a few minutes to reflect and ask questions :

  • Based on your mob refactoring list, which patterns did you observe recently in your codebase ?
  • What did you learn from this kata ?
  • How this practice can be applied in your current context ? 😜

Why this kata ?

  • By having a reversed reflexion (How can I make my code the crappiest possible), people think outside of the box
  • The list of implemented crappy refactoring serve as an anti-patterns list :
    • All the code smells they must avoid in their own code
    • Stuff to fight against
  • Learn Mob Programming
  • Practice automated refactoring : rename, move, extract, ...
  • Because it's fun 😊