In the previous post, my colleague Charles Crain put a stake in the ground saying that it’s never too early to do the right thing in software development.
I can’t disagree with that noble goal. But this raises the question: what is the “right thing” when it comes to software development?
Admitting We Don’t Know How to Develop Software Well
It’s hard for me to admit I’m wrong. It’s even harder to admit I’m wrong when it comes to something I’m supposed to be good at, something I’ve done for over a decade, something like, say, developing software.
Yet some time back I began to sense that, in spite of my years of professional software development experience, there must be a better way of developing software. Perhaps there were techniques, patterns, methodologies, and architectural concepts that I was not using and should be.
For me, this led to a crisis of sorts personally, an impostor syndrome on steroids. Most of the time I hear about the impostor syndrome among software developers the discussion reaches a point where everyone pats each other on the back reassuring one another that feeling like an impostor is almost a sure sign that one is not an impostor, and everyone goes home happy.
But I had to admit to myself that I was a real impostor, if only to myself. I wrote code that, while solving the problem it needed to, was hard to debug, hard to integrate with, hard to test, and bug prone.
Mentorship and Growth
So I started trying to find out what I didn’t know and learn it. I started reading articles about clean code by Uncle Bob Martin and Martin Fowler. I read Test Driven Development books by Kent Beck. And more importantly, I started incorporating the principles I was learning into my code.
I also found some other developers who were on a similar point in the journey as I was, and we began working together to learn from each other.
As the months passed, my code improved noticeably. I was now utilizing SOLID principles, writing (mostly) good automated tests for my code, and learning to refactor as I went along.
Into Uncharted Waters
Just as I was getting comfortable with writing cleaner code on desktop applications, I decided to take the plunge and switch into mobile app development and web app development.
I entered into strange worlds again: new concerns arose about how to architect good mobile apps and large-scale web applications, concerns that I had never had to worry about with desktop apps.
I was bombarded with new concepts like domain driven design, behavior driven design, event sourcing, CQRS, how to design REST APIs. It was an exciting time but also scary; I had so much to learn. I didn’t want to look like an idiot, but the truth was I was a senior developer that had only a few months’ experience in these areas.
Sink or swim? Fortunately, I managed to swim. It was not easy but I was able to learn from other developers who were experts in these areas. It allowed me to get a few years under my belt using all the concepts I had learned: test-driven development, clean code, CQRS, and more.
No Dogma in Software Development
There are hundreds of ways to write a piece of software that does something useful.
Some of those ways may be better or more valid than others, but the fact is that there is no one dogmatic way to write software. We have industry standards, trending topics, better (and worse) ideas, and it is wise to choose the best practices and learn how to implement them.
Because of this lack of true dogma, and the opacity of software code quality, organizations and developers can continue along developing code in inferior ways without realizing they are doing so.
And admitting that they might be writing such inferior code is too scary for most people, because they have been writing software for years, because their jobs and performance reviews depend on perception of their peers and manager, because no one likes to admit they don’t know what they are doing.
Doing the Right Thing
Enter KUKA. I joined the company and was excited about the developers involved in writing the KUKA Connect web application, as well as the technologies and methodologies they were committed to using.
I had been a C++/C# guy for a long time, but now I had the opportunity to learn Scala. Additionally, I had done web apps but never a true microservice architecture.
Now, I was writing microservices in Scala, building into docker images, deployed to AWS using Kubernetes to manage the pods, Cassandra database, Kafka message architecture, event sourcing, Akka actors and streaming…the list goes on.
These aren’t just technology buzzwords. They are tools that make it easier to architect better web apps, that scale and are fault tolerant. Netflix has its chaos monkey; we have our llama of destruction, affectionately named Alejandro.
Doing the right thing requires first knowing the right thing to do. It has taken me several years to learn best practices of software development. It was humbling and at times humiliating, but it was worth it to admit that I needed to grow and learn.
Software development best practices evolve over time. We tackle increasingly complex projects in software, and as we do so we encounter new problems and iterate on solutions. We share knowledge with the software development world on these practices (e.g. through blogs, videos, stack overflow, conferences), and together we have the opportunity to learn from the best out there. A truly exciting time, if we take advantage of it.
I’m grateful to be working with a team now that is committed to learning the right thing and doing it proactively. Many people pay lip service to those goals, and some even try to accomplish them, but here at KUKA we are achieving them by refusing to compromise and letting technical debt pile up.