The story of the Cardboard Ship

Where I explore an allegory of software projects
Published on Tuesday, 27 June 2023

The story of the Cardboard Ship

The Captain and Developer are looking and what they've built:

C: Ha! You said we'd need proper lumber for our ship. Now look at my mighty vessel!

D: Yes, well, we've gotten ourselves a ship now, but recall I mentioned that cardboard might not...

C: Enough of that noise. Set sail at once!

So the ship set sail to bring its trade goods across the sea to the eagerly awaiting colonies

D: Captain, we've sprung a leak. I don't think the hull will hold until we make port. We should make for land as soon as possible and find some lumber to replace the hull.

C: Well, see, we don't have time for that. We need to make it to the colonies before the other guys do.

D: But sir!

C: Silence. Grab a bucket and start shovelling, I'm sure we'll be fine

So, instead of doing the right thing, the developer was tasked with doing the quick thing. So he shovelled and shovelled. The ship stayed afloat, although the water started coming in quicker and quicker, so the developer had to work harder and harder to keep the ship floating.

Meanwhile on the deck, the Captain was overjoyed. The ship made great speed across the sea. The concerns that the developer had brought up was put to shame, because everyone could see that the ship was making great speed.

Before long though, the Captain saw ships on the horizon

C: ALL HANDS ON DECK. The other guys are catching up. Raise all sails! We need more speed.

D: But sir, if I don't keep shovelling, we'll sink!

C: This is not the time for complaining. Speed is the most important thing. Everything else can wait.

D: Sir, we've already raised all sails!

C: Then why are we slowing down?

D: Well, the hull is now filled with water. We'll be at the bottom of the sea before long

C: Traitor! What have you been doing below deck this whole time? You have destroyed my fine ship!


Alright, let's unpack this

Some might say that the Captain is a moron, but I think the key to the issue here is that the Captain and the Developer are seeing things from vastly different perspectives. The Developer raises important concerns, and he spends all of his time just to try to stay afloat, making no real progress, and as soon as he lets up, shit hits the fan.

Meanwhile, the captain sees only a Developer complaining, because there is no problem to be seen. The ship is making good speed.

The captain doesn't seem to understand that he has a guy fully allocated to making sure that they don't drown, and that this could have all been avoided, if he had listened to the concerns of the developer and acted accordingly.

On the flip side - of course - if the Developer had his way; then building the ship would have taken considerably longer, and there may not have been a market for their goods by the time they were done.

This - I feel - reflects very well what working in software projects feels like. We have managers and sales people, who only ever see the surface of the products, and when it looks good, then - to them - it is good. But what they're not seeing, is the crew of developers fighting bad decisions, technical debt, poor (or absent) design, etc.

How do we handle this?

I believe it is very important to keep a tight feedback loop and a good relationship with the managers and decision makers, to make sure that they understand what is going on below deck. Not a lot of complaining and moaning, but giving a clear view of what the state of things are. Sure, we can deal with a lot of mess while still keeping the ship afloat, but eventually, it'll no longer be possible.

Taking care of technical debt, and maintaining a clear design of the software architecture (along with tests, of course) is not an optional task, but something we need to do every step of the way. But on the other hand, it also cannot be all we do. We need to have a good idea of how much time we can put towards maintenance while still moving forward. Dragging the ship onto shore every time there is a bolt that needs tightening is not really an option.

We cannot always make all the right decisions. We'll often misstep. Hopefully, we're not building cardboard ships, but we will bet on libraries, frameworks, providers, and third party companies; and what seemed like a good idea at the time might not be the right choice for the future.

So make sure the Captain understand what goes on below deck and if he cannot be made to listen, then it is time to stage a mutiny before we all drown!



Blog Logo

Hi! thanks for dropping in to pick my brain

I write on this blog for my own benefit. I write because I like to, and because it helps me process topics. It is also my own little home on the web and a place for me to experiment.

Since you're here though, I'd love to hear your thoughts on what you've read here, so please leave a comment below. Also, if you like what you read and want to give a small tip, fell free to:

Buy Me A Coffee