David Schmitz: Everybody should feel safe to fail, to speak up, to have ideas

Did you enjoy David Schmitz's talk from our last edition as much as we did?
Then you should be as happy as we are to know that David is coming again to DevExperience, with another amazing talk on Event Sourcing. Until we meet with David again, here is a very nice interview with him especially for DevExperience blog, that we really recommend reading!

DevExperience: David, you are coming for the second time to DevExperience as a speaker. What do you expect from this edition?

My first DevExperience was quiet surprising. Honestly, I did not expect such an active and diverse crowd. So, I expect even more engagement with the crowd and even more interesting discussions on IT and non-IT related topics.

DevExperience: There will be many new participants this year, so let's tell them a little more about what is it exactly that you do!

I am working as a Principal Architect for my company, a mid-size consultancy of around 600 people. Usually I tend to work with customers on their journey to more digital and cloud native solutions; I know this sounds a little marketing-ish, but frankly, German companies sometimes struggle in adopting modern and leaner approaches.

But basically, I develop solutions with my team of fellow developers. Techstack, process, approach, tools - all tend to vary. I use whatever seems appropriate, from NodeJS to Spring Boot, from AWS Serverless to Kubernetes on Azure.

DevExperience: If you were an architect for a new platform would you go for serverless or microservices on kubernetes or maybe a monolith?

A classical “it depends”. I have seen all options used to great success and to great failure. In general, I am not a big fan of monoliths, as they always tend to degenerate both technically and process wise. Microservices and especially Serverless approaches tend to introduce other complexities, like eventual consistency, monitoring, etc.

I am however a big fan of using Kubernetes as a platform, meaning: get rid of the coding complexity of frameworks and reduce the complexity of your code. For example, instead of complex frameworks for service lookup, just use Kubernetes DNS.

But if I have to choose one, I’d go with a microservice-approach, if the business and team setup allows for it :).

DevExperience: When working with your clients where do you see the biggest gains? From adopting new XP practices like pair-programming, TDD/BDD? Or from a better communication between all the stakeholders and the development teams?

Communication is key. I have not yet seen a project fail (only) because of technology. I guess you could build a successful product using WebSphere and Java 2, event today.

But if social aspects, communication, politics enter the project, then things may get ugly.
So, I try to build an organisation of trust. Everybody should feel safe to fail, to speak up, to have ideas.

I consider pair-programming, TDD and other practises of XP to be like using a toothbrush - essential for growth and quality.

DevExperience: OOP or FP?

I have seen both and I have seen both misused.

I tend to prefer the compositional, immutable style that is inherent in FP. I really like the combination of the approaches, that is embedded in languages like Kotlin. Over the years I have come to dislike inheritance, if I may add.

DevExperience: London or Chicago/Detroit school of TDD?

Honestly, I had to look those terms up ;) And my answer is: no strong feelings. TDD is a great tool and as a tool it can be used for many different outcomes. As such, I would describe my approach as a mixture of both, if that makes sense.

DevExperience: Async communication in microservices is gaining popularity at this moment, nobody wants to build a distributed monolith anymore. So do you see a bigger demand of Kafka or RabbitMQ or maybe AWS Kinesis from the companies you work with?

Everybody is on the Kafka hype train, because if makes for nice Powerpoint diagrams (kind of overstating here, of course). I see, that companies introduce “THE TOOL” before thinking about the business drivers (“WHY do we need a TOOL, WHAT do we want to achieve”).

Most systems I build today rely at least in parts on some form of event-driven communication. I am not keen on introducing heavy weight solutions like Kafka unless I absolutely need it.

DevExperience: For building new microservices what do you think about trying something like go or rust, which compile natively, are faster, use less resources just because they are not vm based (like .net core or java)?

My current approaches are pretty polyglot, so we use what makes sense and align on a macro/intra-service dependencies (e.g. “Let’s all use OIDC, HTTP, REST”).

If you think of tools like Micronaut, I have the feeling, that the resource-question is not dependent on you language of choice. If I’d write a component for Kubernetes, of course I’d use Go - but that is due to the ecosystem.

So, it depends on the team and their preference. Microservice allow us to experiment with technology in a (more) safe manner. You can try things without committing too soon.

DevExperience: We see how the software development landscape is changing at a very fast pace right now and there are many new technologies to master. Do you recommend developers to use their own free time or to ask for additional time at work to learn new things? How can we keep up with this pace which will probably increase even more in the future?

Both. Your company needs to understand that developers are knowledge workers. Investing in knowledge is investing in the future of your company. Understand that, or you _will_ go out of business.

By the way, this goes for most knowledge based jobs. Doctors, lawyers, teachers,… they all acquire knowledge not only in their day-to-day jobs.

Regarding the pace question, do not fall into the trap of “fear of missing out”. Just because you do not know the Newest-Super-Framework-Just-Released-On-GitHub, does not make you a bad developer.
I’d recommend to focus on central aspects, like design principles (TDD, FDD, GoF), cloud approaches (Kubernetes, Serverless, 12 Factor), methods (lean, Scrum). I am not keen on learning and investing into frameworks unless I need them for certain project.
That said: of course, you would be well advised to look at things beyond your day-to-day toolset. Look at something orthogonal. If you are using Spring and Java, check out Elixir. If you are using NodeJS, try to learn Rust. New languages and ecosystems mean new ideas!

DevExperience: If we talked about your expectations, let's talk a little about the participants' expectations! What will they learn from you this year and what should they expect from your talk at DevExperience?

I will talk about our learnings of multiple event sourcing projects - beyond what you need for your CV. As always, I will not try to sell easy answers and solutions. You will learn how we approach difficult things like GDPR and versioning and other topics mostly skipped in the discussion around event sourcing and event-driven systems. And I will not rant on Kafka. It is a great tool, but not for event sourcing, imho.

Lastly, I really hope for interesting discussions. The best thing would be to have a group of event sourcing enthusiasts that totally disagree with my talk. That would be an epic and exciting debate.


So, if you are ready to have an exciting debate with David and spend more time with him, you should really register fast and get your holy ticket, because the seats are getting occupied with speed-light! See you on April 19, at the 4th Gathering of IT Evangelist!