Cruise ships

If you’ve been a software engineer for any amount of time, regardless of where you work, you’ve probably come across that rock star developer that’s lorded by business and management alike. Churning out features like an overclocked assembly line - they’re your classic 10x developer. Meanwhile, the team that surrounds them seems slow, inept and unable to deliver.

From the outside there’s one clear superstar in the team - but that’s not always the whole truth of the situation. Sometimes that developer is truly special. But sometimes, there’s something else going on.

In keeping with the summer holiday season here in the UK, this blog is all about a kind of developer I like to call the cruise ship.

The function of good software is to make the complex appear to be simple

In one of my previous roles I often noted that people were considered intelligent if they knew things that others didn’t. Those that could solve impossible challenges or instantly retrieve archaic knowledge from the deepest depths of their minds were held in the highest regard - but this never sat well with me. I’ve always considered intelligence to be firmly rooted in an ability to learn quickly, and then articulate complex concepts simply.

It’s no coincidence that there were a prevalent number of cruise ships at that company.

So what is a cruise ship?

They’re a titan when it comes to churning out features, and have an undeniably prolific output. But as they steam ahead through the digital sea of deliverables, they leave nothing but a huge wake of choppy waters behind them, causing havoc for everyone unlucky enough to be caught in it. They never look back to see what’s left behind. They never have to deal with the turbulence¹.

It’s often the case that this kind of developer produces software quickly because they code with little concern for long-term maintainability or readability². They don’t give thought to how easy the software they produce is to support. They write in their own style and to their own standards, not to that of the team they’re a part of. Frequently, they’re given the ability to set those standards as recognition for their perceived quality, and do so with little concern for the skill sets of others they work with. They write for themselves, not for their colleagues.

Move fast and break things

To anyone but the greenest of developers, it’s dazzlingly obvious that this development style is damaging over the long term. So how then, is it the case that this kind of team dynamic is allowed to persist or even begin in the first place?

You’ll frequently find that cruise ships blossom in teams with non-technical management or in companies where software engineering is a second class citizen within the company ecosystem.

The reason is simple: if you’re unfamiliar with what good software delivery actually involves, it’s nearly impossible to see the detrimental impact that the cruise ship is having. From a non-technical perspective they are your team’s hotshot, carrying everyone else along on their shoulders; it’s impossible to differentiate them from a genuinely exceptional software engineer from this viewpoint. Teams that allow cruise ships to flourish are measured by simple KPIs, chief of which is delivery output - those running the teams are seldom involved in the detail and nuance in any meaningful way.

So if you’re running one of these teams (particularly if you’re not technical), how do you spot when this is happening?

The key giveaway is in how other team members interact with the cruise ship’s code. The most likely sign is that after they touch a piece of code, other members of the team see a slowdown in their output when interacting with it. However, in severe cases team members may try to avoid that code altogether. This can be subtle - it’s not always easy to tell why output of a developer is dropping. It could be due to hard-to-work-with code, but it could also be because of unexpected challenges, unfamiliar frameworks or just having a bad day.

One surefire way to spot cruise ships is simply by encouraging your team to discuss issues openly³, listening, and keeping an eye out for whether or not most of the inefficiencies people are raising centre around the output of a single person.

The biggest issue on software teams is making sure everyone understands what everyone else is doing

When you’re sat inside a team that’s dominated by a cruise ship it can be crushing for morale. You watch as one of your colleagues churns out subpar code, and is yet somehow praised on a weekly basis in town halls and stand-ups. Meanwhile, you’re busy dealing with the production issues and maintenance nightmares they produce, constantly trying to refactor their undocumented spaghetti code and “clever” solutions into something that the rest of the team can cope with.

It feels extremely unfair.

This is precisely why allowing a cruise ship to run wild is so destructive in the long term. Eventually those disillusioned developers will either stop trying or leave.

If you find yourself trying to right the course of a team that finds itself in such treacherous waters, it’s vital to shift focus away from delivery speed and onto other factors like quality and maintainability⁴. The art of software delivery is far more than blasting through deliverables as quickly as possible. It’s about writing code that your team (and future teams) can understand. It’s about making sure things are secure and robust. It’s about creating application architectures that are flexible enough to change over time but concrete enough to reason about.

It’s also important to place emphasis on how to make the day-to-day lives of your engineers easier. By doing this you shift focus onto the task at hand rather than those who are to blame. Speaking openly about how to get the job done more efficiently is an excellent way to give team members a chance to draw out the problems that a cruise ship creates without pointing the finger directly at them. You can also ensure that proper recognition is given to those that deal with production issues professionally, take time to help their teammates or take time to document their code properly. This can be via qualitative means like public, positive feedback, but it should also be via more quantitative measures and KPIs⁵.

Teaching something to a fellow programmer doesn’t take it away from you

Up until this point, I’ve written with the implication that those embodying the cruise ship mentality are exclusively doing so maliciously or selfishly. This isn’t always the case - it’s possible to fall into this role entirely by accident.

As your skills advance and you find yourself climbing the career ladder, it can be easy to take your knowledge for granted. Once you’ve overcome understanding something hard, it’s amazing how quickly you can forget that there was ever a time when you didn’t know it in the first place. This is why it’s essential to write for your team’s skills and to spread knowledge wherever you can.

Not only this, but we can often fool ourselves into thinking that our knowledge is universally applicable. The more experience you have, the more likely you are to fall into this trap. Those that excel at something are often given more time to do it - so if you are your team’s superstar at delivering features, it’s likely you’ll get given more and more tasks that focus on delivering features and less of everything else.

But if you don’t have to debug and support your code, you don’t know what it’s like to support it.

If you don’t write tests for your code, you don’t know what it’s like to test it.

If you never have to learn how what you’ve written works, then you don’t know what it’s like to try to understand it.

When you’re excellent at writing software, but blind to how your daily experiences differ to those of your team, it can be all too easy to become part of what slows them down, despite best intents. You’ll question why those around you struggle to stay afloat, blissfully unaware that you’ve become a cruise ship yourself⁶.

Don’t be a cruise ship.

Ask your fellow team members for honest, constructive feedback. Spread your knowledge to others and make it easy for them to pick up where you left off. Put yourself in the shoes of others by doing the less glamorous work like support, documentation and testing. And above all, take time to think about how your work impacts the team around you.