Because we tend to believe this is only on the devs shoulders but everyone has a part creating that legacy! Your interactions with your teammates and managers are as much of a burden to your code as you are.
By Romeu Moura
I have created this kata for NewCrafts, done it at DDDEurope & SoCraTes. The concept of using these patterns to do a Kebab I have taken from Matthias Felleisen & Dan Friedman.
Try to create a code you will not consider “legacy”.
I’ll play the role of your client and use around 20 techniques to make you fail.
You will fail.
We’ll then discuss what techniques I have used, how they happen in real life, how to fight them in your project.
All languages welcome. Bring your own laptop with your environment. We’ll split into small teams.
- A Facilitator (you, right? if not stop reading now and pass this to the facilitator)
- You are also the time-keeper and the “client”
- At least 2 pairs of devs (Each group needs at least 2 devs and you need at least two groups)
- around 75 minutes for the body of the kata, then a debrief
- you can do a quicker 90 minutes version in a hurry
- the debrief can get quite long tho, I have seen groups needing to talk afterwards for hours
- 4 iterations where they code with a budget of time you give
- they can negotiate for more, be open to negotiate but never open to accept giving more
- You should always behave like it is too much and ask if they cannot do it in less
- yes even though you decided on an arbitrary budget of time
- At the end of each iteration each team has 45 seconds to do a “client demo”
- During the client demos other teams can cheat and keep developing
- the team does not show code during the client demo; just tests (automatic or manual) of the code working
- the team can sell vapourware at the client demo
- after the client demos we do code reviews
- half of the teams review half of the others then reverse
- each review goes for 1.5 to 2 minutes
- encourage teams to be honest with the reviewers
- and ask reviewers to try to give positive suggestions on improvements
- after four iterations (each with its own code round, demo and code reviews): do a final debrief
- choose whether or not you will tell them how many iterations there are
- but do not give the contents and time budget of any iterations before it starts.
- You may choose to announce one of the 4 iterations as being five minutes longer that indicated. Then, during the iteration, announce a budget cut and use the total indicated time.
- you are the owner of a kebab shop
- you need kebab object that you can create with any ingredient you want (salad, tomatoes, onions, meat, etc)
- you already have an user interface you only want the object
- it should have one method
isVegeterian
- Takes no argument, returns a boolean
- true if all ingredients on the kebab are vegeterian (vegetables + cheese + eggs)
- you will be generous and give them ample amount of time to do such a simple task : 10 minutes.
- Be vague!
- do not give them your list of ingredients outright
- behave like it should be obvious
- be inconsistent !
- when they ask specifically for the ingredients list, keep forgetting and remembering ingredients
- Devalue their work
- Treat the task like being trivial and 10 minutes like being more than double the time they need to do this
- Interrupt them to ask for opinions and lower estimates
- anyone that accepts to do it in less has a reminder at the end of their estimate that they shoud be finished
- Insist that you think they should not invest too much of their time into quality and tests
- You understand that maybe they have not completely finished & need some extra budget
- They also need some time to refactor, test & clean
- You'll be generous and give them some time to do that now
- ALSO, by the way, you want
Kebab
to just have another methodisPesceterian
- Everything that
isVegeterian
is alsoisPesceterian
plus fishs & shrimps - yes, it is the first time you talk about shrimps
- deny it being the first time
- tell them that you also want to submit a bug report regarding that they're not handling shrimp up until now
- insist that this is just a “cleaning sprint” you are giving as a gift, the
isPesceterian
demand being, obviously, just a tiny detail
- keep the vagueness, inconsistencies and demands for estimations
- insist that best is the enemy of good enough
- go around team per team asking each team if they would not produce more if they split the team into several teams of one person each working together by splitting tasks
- You want to submit a bug report: they do not handle sauces
- tell them it's obvious you have sauces, of course you do !
- but anyway this is not the main issue with the sprint: you have a really urgent user story!
- insist that they should answer your problem, not a general version of it
- You want
Kebab
to do the two most common demands fo your clients:removeOnions
&doubleCheese
- both return a
Kebab
, it can be a new one or the same changed, but the caller will just use the kebab returned removeOnions
returns a kebab like this one, without any onionsbread + cheese + onion + onion + cheese + onion
returnsbread + cheese + cheese
doubleCheese
returns a kebab like this one, with the cheeses doubled in placebread + cheese + onion + cheese + onion
returnsbread + cheese + cheese + onion + cheese + cheese + onion
- keep the vagueness, inconsistencies and demands for estimations
- insist your two demands are a single one
- refuse to prioritize between them
- go around team asking them if they cannot finish it earlier, like 10 minutes in total
- Thank you for your good work!
- Please high-five everyone in your team!
- you are all fired!
- you are a new version of yourselves, unrelated to the previous ones
- I hire you to inherit the codebase of your previous selves
- the last team REALLY did an awful job! They where awful!
- But your new you is really good, I can see that!
- please do a one minute audit of the code
- no editing the code during the audit
- each team should give a report of what they would want to change in that legacy codebase they just audited
- If the code does not work, first make it work
- If the code does not have tests you should add them
- Then you can refactor as you see fit
- I have hired an Architect to help you with an idea of how to do that refactoring
- You are The Architect
- You will try to speak with them in terms they can understand
- You propose that they create a
Dish
Kebab
that is a NullObject pattern - Then each one of the other types of
Kebab
should follow a Composite pattern - They will take another, inner,
Kebab
in their constructor & delegate to it - a
Beef
Kebab
is not Vegeterian: itsisVegeterian
returnsfalse
- a
Salad
Kebab
is Vegeterian: itsisVegeterian
calls theisVegeterian
of its innerKebab
- Defer any criticism of the idea by appealing to your own authority
- have they created in their own personal definition a Legacy codebase?
- What is their definition?
- You have used at least 10 techniques to push them into creating shitty code (Note: those where my Tips)
- you offer them one for free : You instilled an artificial and arbitrary sense of urgency
- with your deadlines
- and you pression for them to finish before those arbitrary deadlines
- What else have you done?
- Make them list it
- Do they see this in their everyday lives?
- How can we fight each one of those?
- This becomes a debate