Code Retreat 2017 retrospective
In general, this year is much better compared to previous years
There are several important points that I need to write down
Typically, the main reason for me to do code retreat to help developers in the community to expose more to TDD/craftsmanship.
Recently, I asked myself question: “How come it’s not easy to adapt TDD, automated testing which should be the core value of any efficient teams?” I don’t think that people is lazy or people is resistance, I think as the industry, there’s lots of ambiguity in how people should approach TDD (SOLID principles, 4 simple rules of design, etc … are too generic) and agile practices (agile manifesto, etc…)
How can I apply SOLID, 4 simple rules of design into my day to day jobs?
What’s the most important reasons for developers to write automated tests? is it testability design, is it executable documentations?….
what’s the different between integration/component/API tests? should we care?
when I discuss about unit tests with QA, typical answers I get is that it’s programmer tests? IT’S SO NOT TRUE? It does contain many behaviors of the systems, some behaviors are at very low level and business people shouldn’t care about, but I believe MOST OF THE BEHAVIORS could and should be expressed at high level domain language and can be used as executable documentation for different stakeholders such as QA/Non technical people. Should we call those tests as behavior unit tests instead of unit tests?
How can we make the TDD/Refactor/agile practices easier for people to adapt?
- Maybe, shrink the change?
- Maybe, there’s lots of things can go wrong but there’s few things that you got to get it right, so script critical moves?
- Maybe, Looking for bright spot (examples) so people can see the benefits and start small?
- Maybe, tweak the environments to encourage the right behavior and discourage the wrong behavior?
I think code retreat is one of the good place for me to find the answer to that question.
I’m very glad to to get some help from Lori this year and she has very good recommendation on how we can improve the code retreat experience for people
- It’s fair to say full day code retreat is a little much for most people to take. Code retreat could be organized more often and with shorter period (maybe around 4–5 hours in the morning)
- Most of the time, half of the people registered don’t show up, is there anyway we can ask people to confirm their attendance?
- Most of the attendees said that they wouldn’t want to attend it again as they wouldn’t be interested in doing more different sessions and they wonder if the format of code could be changed to something so support different interests such as devops code retreat, legacy code retreat, how to write mock easier code retreat, etc ….
- The facilitator should be more active and walk around the pairs to ask more questions and push the attendees out of their comfort zones. The facilitator shouldn’t code as this is not their day, and they should do their best to push the attendees out of their comfort zone.
In general, I enjoy this code retreat as I kind of started to see my own specific goals that I want to get out of code retreat which would probably give me more motivations for me to do this for a long time.