Category: Personal Stories

I’m Devin and my title is Principal Software Engineer on the Cloud team. Here’s what I do at KUKA and why I enjoy working here.

I work on the backend team, a small group of three people developing the server-side components of the KUKA Connect web application.

KUKA Connect is a web app that gives our customers the ability to monitor their KUKA robots, and one day to preemptively diagnose potential failures.

The People

Every person on the team and in the office is enjoyable to work with: pleasant, helpful, and capable.

We have a cooperative atmosphere, and on our backend team we often do “mob programming” where we go into a room together and have a group coding session to implement important features. This practice 1) brings the team together, 2) gets everyone up to speed on coding style and feature architecture, and 3) facilitates better code through the group dynamic (three heads are better than one).

I’ve never worked at a company that fostered such a collaborative environment. Oftentimes it is wrongly thought that having developers code together slows down velocity: the opposite is true in my experience. By working together, obstacles are overcome more quickly and development effort is more focused.

We have some talented people on our team, and these people share their wealth of knowledge through mentorship, so everyday affords the opportunity to grow and learn.

The Technical Aspects

It’s one thing to work with great people. We’ve got that. Pair it up with cutting edge software development practices and tools, and now you have something really special.

We are writing a scalable web app that is global in scope with massive data pouring in every day. We need near 100% uptime; we need to be able to dynamically scale up the web app based on load; and we need to be able to evolve the architecture as we move forward.

To solve these challenges, we employ paradigms and tools that are industry leading: test-driven development, event sourcing, the concept of a log (we use Kafka for this), a distributed and highly scalable database, data streaming (Akka), and microservices. This is in addition to fundamental practices like dependency injection and interfaces/protocols/traits.

We deploy our system to Amazon Web Services (AWS) and manage our app through Kubernetes with Docker containers. Each microservice is packaged up in a Docker container and then one or more replicas of it are deployed by Kubernetes as pods to an AWS instance in our cluster.

We capture live metrics on all important aspects of our app and have a huge TV that shows the DataDog dashboard for our different tiers. When something goes wrong, we know it quickly and can fix it.

The bottom line: being on this team has leveled up my software experience by leaps and bounds.

The Product

KUKA Connect is our first product. We just released it. Industrial robots like the ones KUKA makes have been around a long time and do things like assemble vehicles.

But the software for monitoring and managing these robots has developed more slowly. We are changing that with KUKA Connect, giving our customers unprecedented ability to manage their robots: visualize what each robot is doing, know when maintenance milestones are coming up, find out when a robot hits a critical fault, and see important operating data about their robots.

We have already been getting feedback and the good news is people love the app and want even more features. So we have lots of great work to do.

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.

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.

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.
[/et_pb_text]
[/et_pb_column]
[/et_pb_row]
[/et_pb_section]