Visiting Rabobank's meetup about clean architecture with uncle bob.

Last Friday (8th of February) I went to this meetup. It was with the famous software engineer and author Robert C. Martin, better known for his nickname Uncle Bob.

I'm writing this blogpost so you didn't have to visit this meetup.

I signed up to attend the meetup before my internship at Flitsmeister started. The meetup would be at the 5th day at the job. I was fortunate enough to be put on the list of attendees and to get a day off so I could actually attend the meetup.

If you do want to see the whole session for yourself, it is posted on Youtube.

This meetup was located at the Rabobank, a big bank in the Netherlands.

Rabobank headquarters

After a short introduction, the meetup was going to start.

Introduction

My goal at the meetup was to learn some more about architecture and to share this at my internship company, Flitsmeister.

The first talk was about "Clean Architecture and Design" and "Architecture: The Real Software Crisis". Uncle bob combined these two talks into one big one.

Some of the take-aways that I got from this talk are:

• Test driven development is a way to speed up development. There has been an experiment where someone would code the same challenge with and without TDD on different days. The ones with TDD were always a little bit faster, even though it should cost more time to type the extra code.
• The key to speedy development is to prevent slowing down.
• The key to fast development is to have a clean architecture. Thinking about the design of a system up-front will allow for a faster development process. It's also a good idea to revise the architecture after a while.
• Management will often try to speed development up by forcing quicker development. This will result in developers making worse decisions about architecture and TDD.
• It's your job as a developer to not create roadblocks for yourself.
• Whenever a new feature gets added to the system, it's always about: "how would this piece fit in the puzzle". The easiest way to achieve this is to make every piece a square.
• Good architecture starts with defining the purpose of a system at the highest level. You shouldn't see, "oh this is a Java or Angular project". No, you should see "oh this project is initiated to solve problem x".
• It's important to have clear boundaries in your architecture. For example: I/O (like databases) should be completely separated from the code. So you don't want to end up with SQL queries in a RESTful API method.
• It's a good idea to be skeptical about using frameworks. Frameworks are mostly made for the benefits of the author. Frameworks should only be used when it's solving a hard task that will save you a lot of time.

Good coding challenge for any programming language: Try to efficiently convert roman letters into numerals.

Especially the part about using frameworks resonated with me. In a previous school project my teacher recommended the same to us. We ended up building a microservice registry and monitor with about 30 lines of code each. I'm not sure which framework we were considering at that time, but for example using the Play framework would be overkill to use for just a small functionality that can be built and maintained by your own team.

Next up were two breakout sessions of which just one I got some new information from. The sessions were given through headphones where you could switch channels to listen to another talk given on the same stage, which is a bit weird but it does work.

Two different headphone colors.

The talk I got some value out of was given by Roy van Rijn. He is a software engineer working at Open Value. He just started as a director in the Rotterdam part of the company. The company differentiates itself by focussing on knowledge sharing next to doing client work. I've been to a couple of their Meetups as well.

His talk was about his experiences with a team that completely renewed a software system, using a new technology stack. Later that same team made the decision to go for Microservices even though it wasn't really necessary. What I learned from that talk is that you should carefully switch over to the new system and then you can just shut the old system down without worry.

The guy shutting their old system down was like: "I'm going to do it guys, I will shut down the old system now". The other employees were just standing there like: "allright, go ahead, we already know the new one is working, so it's no big deal".

You should not do or try Microservices just because of the hype surrounding it.

Uncle bob talked about the hype train of Microservices. What tends to happen in the software industry is that old concepts get branded into a new thing and it will make them popular. For example the concept of AI has been around since the start of software development.

Roy talked about their team not reaping any special benefits from switching over to Microservices. It's not a bad change either, it just didn't add much value for that team.

After that I listened to a talk given by Sander Mak, essentially saying the same about Microservices. It will only help cut down the costs of development (not just money) in bigger projects with a longer duration. He provided a middle ground where you would use module systems to improve the cost of development.

After these breakout sessions, uncle Bob talked about the project management side of software development.

Uncle Bob talking about Agile.

His next two talks are "Agility and Architecture" and "Specification Discipline". Some of the take-aways I got from that are:

• Use the first sprint to find out what the client wants and how your technology stack is going to look like / work out. Uncle Bob recommends to not just focus on the requirements, but also look towards potential solutions. This will start the process described with the twin peaks model where requirements influence your software architecture and the other way around.
• The reason that Agile came to be is that it's a good way to let managers know when they are screwed. It allows for them to work with data to see the status of a project instead of asking the team how they are doing. Because the team would say "it's all fine" and think to themselves: "should we tell him what's going on?".
• Data about the status of project must dictate the decisions being made.
• When you are not going to meet a deadline, you cannot always just add more people to the team. That will initially slow the existing team members down. This could only be a good strategy for a long-term fix.
• Senior developers should always assist and help junior developers. This way both parties will learn. You really do learn the most by teaching to someone else.
• Product owners will learn from failures. So experienced product owners are valuable.

After that the meetup was concluded by a Q&A session and then we went for some drinks.

Ending the session with a Q&A session.

I hope you learned something new by reading this blog post about the clean architecture meetup. If you want to read more about software development and lifestyle, make sure to follow me.