As developers the one thing that’s central to everything is communication. We’re responsible for communicating our ideas and intentions to others and to our future selves. Whether it’s through the code itself, its token names and comments, or through its accompanying documentation. Whether it’s through the commit messages: title and description, or through the pull request content.

It’s often been said that we should optimise our code for reading, not writing, as we spend more time reading it than writing it. Well the same is true for our writing. It should be optimised for the future reader. You aren’t, or shouldn’t, be writing just for its own sake, to tick a box, or so you can say you have documented your code. You’re writing to span the temporal gap between whatever it is you’re working on and its future maintenance requirements. You’re writing to have, an admittedly one-sided, conversation with future maintainers. Often for yourself.

It wasn’t waterfall. It wasn’t scrum. It was both and it was neither and it was doomed to fail from the get-go.

Once you’ve been doing this for a while, you’ll understand that pretty much every aspect of the discipline, at least in a professional setting, has a trade-off.

To put it as simply as possible, we can’t have everything, we can’t do everything. At some point time, money, deadline pressure, prioritisation of other projects or one from a myriad of other concerns will cause us to have to make some tough decisions.

Businesses are usually around for longer than individual employees’ tenures. At some point, someone else has to take over your workload.

If you have an owner mindset rather than a custodian mindset this is difficult. Handovers are not easy. Trying to cover all bases and think of everything you might need to get from someone during their notice period is going to result in at least some of their knowledge being lost.

Framework choices can be critical. The wrong choice is going to cause a big increase in the amount of technical debt a project has and can harm the onboarding process for new employees, which already carries a high opportunity cost.

Problematic choices:

• Flavour of the month
• Too dated
• Custom

All of the above carry a high chance that you won’t be able to find a new hire that knows the technology involved. Obviously with a custom framework it would be impossible! All you can do if that’s what you have is hire someone with a solid and varied background and strong knowledge of the fundamentals of software engineering.

Opportunity costs are so often missed in a myriad of different areas.

For software engineering we of course have them too.

If you’ve not read The Mythical Man Month, you may have at least heard its central premise:

Adding resources to a late software project makes it later

Or perhaps more likely:

9 women can’t make a baby in 1 month

When a resource is added to a project, someone from the existing team needs to take the new person under their wing and help them get up to speed. That person could be doing something else instead that more directly adds value: this is an opportunity cost. That cost is excluding the time cost due to extra lines of communication that the aforementioned book primarily focuses on.