On the 30th of August 2018, I attended a workshop about “TDD, DDD & Teamwork” given by Pim Elshoff and Joop Lammerts. The venue was Vrieling Adviesgroep, situated in a small village of Dedemsvaart, Overijssel.
Thanks to the local Dutch group VechtdalDev, such sessions occur four times a year, free of charge. Primary language is Dutch and everyone is welcome.
Reason to join
I’ve decided to go there because the topic sounded interesting and compelling to me.
Over the last two years, I crunched a few books about Domain Driven Design and Clean Architecture. Additionally, two big enterprise projects I was part of, gave me a hands-on experience. But at the same time, they prove to me how complicated and different DDD modeling can be.
Since then, I keep studying this topic and take every occasion to face my thoughts with others.
Coming to VechtdalDev meeting, I wasn’t aware this is going to be a coding workshop and I didn’t know anyone there. Because the venue was 120 km from my home, I was a bit late.
So once I arrived, still trying to catch my breath after cycling, I had to set up my environment in a moment. Neither I have time to read the PHP project instructions nor fill up the given questionnaire.
I become part of the 5-person team and we started to work on my laptop, which was also connected to the big screen. There were other teams of 3 to 5 people, but they moved to others rooms, so we didn’t have much interaction with them.
The first hour of the workshop focused on implementing User Stories. They were gradually increasing in complexity. Every team member had around 10-15 minutes to deliver as much code as possible and then switch. The code could be ugly, the only thing that mattered was to use Test Driven Development in PHPUnit. Once you get stuck, you could ask your teammates to help you.
After this, we had a little break and then the second hour of the workshop started.
This time, the person who typed the code was not allowed to speak. Others teammates were discussing the given User Stories and suggesting solutions. If the person behind the keyboard wanted to intervene, he had to hand off the typing to another developer.
In our team, I was typing the whole hour, while the other four trying to come up with a proper solution. We somehow focused on refactoring the previous code and this consumed all our time. I was OK to code all the time because it was my laptop, my IDE configuration, thus I knew all the nuts and bolts of it. Moreover, the previous exercise has shown we had to switch the IDE settings far too often.
After this part, all teams met together again in one room. We had a short Q&Asession and then the time for networking started.
In the middle of the workshop, I filled up the questionnaire, without analyzing it well enough. My initial answers were as follows
- At the start of a new project, I tend to
- Think big and work out the general picture
- Work out some details and start coding to get a better understanding
- While coding…
- I only start coding when I see the bigger picture
- I regularly throw code away and start over
- I can easily talk and type at the same time
- When someone shares an idea with me, I tend to
- See potential problems and risks
- Get ideas of my own
- When I face an obstacle I tend to
- sit down and get to the bottom of it
- park it and work on something else for a bit
Then I came back to it next day and studied the concept behind divergent/convergent person type. Looks like, based on those answers, I would be the one who tends to push on the brakes than the gas, showing pessimism.
The place was wonderful, easy to access and offered plenty of office space and parking lots.
I was very surprised by their warm welcome, positive attitude and understanding. They waited for me when I get late and my poor Dutch was not a problem at all.
It was an interesting experience and I enjoyed it a lot. It was something unexpected, full of hands-on coding and interaction with people.
Workshop agenda and schedule
I prefer to know the schedule of the workshop upfront and all its pre-requisite.
I think people who are not programmers could be intimidated by the idea of coding. People who don’t use PHP and didn’t bring their laptop could be left alone or put in teams that use the foreign language to them.
I could enjoy it more if the Github repository were accessible before the workshop.
I missed information under Meetup Event about bringing a laptop with PHP 7.0 environment preconfigured.
Workshop first hour
To me, Team of five was too many. It was actually more disturbing than helping to the person who was reading the story or writing the code. I felt that people who set close to the laptop took the attitude of “involved”, while other as “detached”. I tended to talk to the closest person to me. Unintentionally, the ideas or remarks from distant ones, couldn’t get through. For me, even simple mistakes were hard to catch up. Additionally, this 10-15 timeframe caused more troubles than good. It put an unnecessary burden on the team.
To me, the right number of people would be two, most three. They all should sit next to each other and actively take part in the assignment. This 10-15 timeframe per developer should start only after the User Story was well understood by the programmer. It should also be a soft time deadline. I observed it was more important for developers to stick to this timeframe rule than to actually understand the progress in the codebase.
Workshop second hour
To me, this approach was more promising than the one from the previous hour. Also, having more members in a team was working to our advantage. Ideas were discussed in more details and from different angles while emerging solutions were sharper and easier to implement. The collaboration was improved and it became more apparent that we all work towards the same goal. Also, I had a feeling that implementation crafted that way, will stay longer in our codebase, without unnecessary refactoring.
I suggested to the team to diverge from the idea of switching the coding person now and then. I came to conclusions that picking up the most efficient typing guy is improving the team speed significantly. In the team of five, if four are OK with the solution, another guy is hardly ever going to bring an amazing breakthrough. In a normal situation though, typing guy shall also be involved in the design phase.
TDD & DDD part
I thought this session will be more focused on TDD and DDD part, but it was actually some type of a Teamwork workshop. It was nice to jump into a random team and see how we all perform, check our attitude, and use a bit of TDD along the way. In practice though, nobody was guarding and verifying if the process of TDD was applied correctly.
IMHO, this workshop would be more valuable if the presenters spent more time showing DDD projects from their development trenches. People learn by examples, so the more code samples with throughout explanation, the better. I also missed the discussions about use cases of DDD and TDD. Would be nice to know when those techniques actually fall short and old-fashioned approaches become more profitable and advisable.
Although it’s stated in Github “Please note that “tend to” does not mean one or the other exclusively. Just go with the first choice that comes up for you.“, I still think some questions are hard to answer because there is either a lack of a neutral option to choose or answers are too misleading.
The question “I can easily talk and type at the same time” is far too generic. If I answer “disagree”, I’m automatically becoming pessimistic. Actually, my answer would be two folds: “agree” if I do pair-programming or hunting for bugs. “disagree” if the implementation is clear and I have lots of things to code – in this case, I don’t want to be disturbed, it’s counter-productive.
In the case of the question “When someone shares an idea with me, I tend to…“, I would answer both at the same time, plus correcting the second answer to “Listen to others and came up with a counter idea if necessary”.
The last question states “When I face an obstacle I tend to...” . In order to be more “optimistic”, the answer shall be “park it and work on something else for a bit“. I think starting other task is counter-productive. It would sound completely different if it was about getting for a walk, refresh the mind, take a nap, while still continuing the started task.
I think those conclusions cannot be taken too seriously, because programmers attitude is hard to classify into one of two “made up” bags. IMHO it requires much deeper study, especially when it touches a person’ psychology, their various backgrounds as well as their past development teams and projects.
I totally recommend VechtdalDev meetup group and I hope I will be able to join their meetups as often as possible. There are lots of skillful people out there, thus there is a lot to learn from them.
I thought that most of the web specialist from the Netherlands live and work somewhere around the big cities as Amsterdam, den Haag or Rotterdam. I must admit that I was wrong again 😉
If you enjoyed this post, then make sure you subscribe to my Newsletter