Menu
In anticipation of Sander Hoogendoorn's session, Microservices From the Trenches. A Real-Life Practical Guide Through the Architecture, Design, and Code., Richard Wallintin (WPS - Workplace Solutions) had a number of questions for Sander about taking small steps and making mistakes in software development and why working with small, agile teams is good.
“Small Steps” is a recurring theme in your work and talks. Can you sum up why taking small steps is so helpful almost everywhere?
If you are trying to change - whether as an organization, as a team, or as an individual, and both personally and professionally - you can at most try to set the dot on the horizon. However, as soon as you start to experiment, the outcome of each experiment might change your direction. Therefore, you can only take one step at a time. The smaller your steps are, the smaller the delta, and the easier it becomes to make the change, and then take another step. As an example, if I look at the way we do continuous delivery and deployment at iBOOD now, there's no way that we could have imagined 18 months ago when we started this journey, that our delivery would operate exactly as we do now. We took numerous small steps and improved our delivery experiment by experiment.
Can you imagine to ever lose interest in writing code? Many people working in similar positions/roles like you say they don’t get to write code, some say that is not important for doing mare strategic work. How do you feel about these notions?
I have been writing code since 1978 and making a living from it since 1987. I still thoroughly enjoy writing code every day, especially when I can do this in pair of mob programming sessions with my team. Whether or not people find code not relevant for doing more strategic work doesn't really matter to me. I just love to code, also in the various CTO roles I've had so far. I would not easily take on a role where there's no coding. For me, writing code is much more relevant than achieving strategic roles. For me, it's about joy, not ambition.
Doing experiments, taking small steps, shorter cycles etc. is supposed to make failure less painful. In your work at iBOOD, how frequent does the team “fail” at something – and do you have any rituals around failure?
We fail almost every day. Working in a team on over 100 small repositories is never flawless. We're only human. The good thing about making small steps, while having everything fully automatically tested and deployed is that it's almost always ok to make mistakes. We all do. I'm no exception, nor is anybody else on the team. However, we can usually roll forward immediately, which resolves most issues within 5 minutes in production.
You also advocate for small, agile teams. How do you counter the criticism that cross-functional small teams are not realistic, because there are so many skills and disciplines needed to deliver software that cannot be covered by a handful of people?
Software development is the most complex field to work in. Technology and circumstances change continuously. Therefore, the silly 7 plus or minus 2 rule that some approaches propose doesn't really cut it. In reality, you need teams that have ALL skills on board to deliver value. Depending on the complexity of your landscape, such teams, which I usually refer to as collectives (in my new book), range from 12 people (my current team) to even 40 people. What I try to establish with such collectives is that every item (and these are all different and require different skills) is picked up by dynamically formed microteams, teams of usually 2 to 4 people that then deliver that particular item, split up again, and pick up following items in different microteams. I've been using this approach for about a decade, and it works (for us).
Where do you stand in the continuum between standardization and autonomy? Does a collective with transient micro teams require a very consistent technical landscape? E.g. is it beneficial to use the same programming language throughout frontend and backend – and how is agreement achieved without hierarchy?
When working with larger groups of people on de code bases in a landscape, it is always beneficial to share guidelines, techniques, patterns, and especially architecture. We have over 100 code bases, all microservices, micro-apps, and workers, that share a common architecture. If we wouldn't do this, we wouldn't share code ownership, which we highly value. That gives both some boundaries but leaves a lot of room for individual taste. We do have mandatory static code analysis in the pipelines and thus test everything. So, standardization to a certain extent, but with lots of autonomy.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
