(writers note: This post was originally intended for today.jaoo.dk but I thought I'd start by posting it here as a draft since nobody reads this blog anyway :-) Thanks to Rolf Njor Jensen for co-authoring this post!)
Have a shaman - be a shaman
Every team needs a shaman. A shaman is person who tells stories. So, when someone in the team asks "Why the hell is this code like this?". The Shaman tells the story of this partibular piece of code, its past and how it fits into the rest of the stuff.
Strip away everything you can
When you start to strip away stuff that has no real value in your codebase. You of course will get a simpler system. But another advantages is that other unnecessary stuff pops up and becomes visible.
Use transitional architectures
Developing software is performing structural changes on existing bodies of code, occasionally adding new pieces of code and chipping away old, unnecessary code. If you want a nice loosely coupled architecture with good performance but your current architecture is a big pile of crap. Then it might sometimes be necessary to take one step at a time and for instance start by removing all God classes. An architecture with no God classes then becomes a transitional architecture (or you could say a temporary solution). This architecture does not fully fulfil the goal but is one step towards the wanted solution. It is very important that everyone are aware of the fact that the transitional architecture is not the final solution.
Dan gave another example of a transitional architecture namely to get from the current build system to Ivy. Maven was used as a transitional solution. Maven is this obsessive compulsive friend. When you bring Maven on a date it brings all its friends from all over the internet. The obsessive compulsive disorder has one advantage: Since Maven is very rigid about the placement of different parts of the source less duplicated code is created (since developers discover that the needed code has already been developed before introducing a duplicate solution). After Maven had done its tricks the team was ready to move to Ivy. As Dan put it “When bringing Ivy on a date, Ivy asks if he can bring one of his friend who will clean up the house during the dinner”.
Avoid Standup Stasis
Dan gave a nice demo of how daily standups should not be performed. It is hard to replicate in words so I will try with a strip instead:
The team that Dan started working on as an consultant had stopped doing daily scrums. Dan asked how they used to do it and the team did as the above strip tries to explain – i.e. everybody on the team just reported. No one listened and no one commented on others statuses – Scrum Stasis. The team refused to start doing scrums again so Dan did a clever trick. The next day he said “Well I've just had this fantastic idea: why don't we meet each morning and have a chat about the rest of the day answering the question - how we can have the best today?”. The team thought this was a brilliant idea and this way Dan North reintroduced daily scrums (without using the term). Finally, here is a list of points and citations that did fit into this post:
There is always a reason
Ensure deterministic deployment
You shouldn't "buy" architecture
Nice architects listen, and are not-very-self-important.
“Take a pile of crap A, take another (larger) pile of crap B, and make them into a nice lightweight group of services.”
