Our code is at its best when it is not ours anymore

Baptiste Le Bail — Thu, 01 Jul 2021 13:00:39 +0000

I want to work with code that belongs to no-one.

We are, as software engineers, participating to the whole IT ecosystem, even if we are neither precursors nor working on cutting-edge technologies.
The vast majority of us do not work at GAFAMs or any shiny new startup.
That being said, I think we should always consider ourselves, at all times, as craftsmens and aim at the best version possible of our code.

To me, this best version can only be achieved when our code is simply not "ours" anymore.

"our code" is the code we produce that will be used in any way possible, even if it's only used by ourselves.

But what do I mean by "not ours anymore" ?

There is code because there is a project, whether it is personal, open source, for a private company, or whatever.

I share the strong belief that the main goal of the vast majority of projects in this industry should be to remain easily maintainable.
Otherwise, these projects will inevitably become unsustainable, either technically and/or financially.

In a nutshell:

Is the code easily read and understood ?

No ? It's still ours then.
We could think of a simpler, clearer component architecture, and better variables/methods names.

Is the code style homogeneous ?

No ? It's still ours then.
We could set up a code convention and even enforce it with static analysis tools.

Does the code have tests ?

No ? It's still ours then.
We could add tests to get a fair bit of coverage and prevent unavoidable regressions, in addition to showing how the code runs the way it's supposed to.

Does the code produce a good feedback ?

No ? It's still ours then.
We could add comprehensive logs and error messages.

Is the code documented ?

No ? It's still ours then.
We could write a clear README, a component diagram or a full blown documentation.

Is our current brain required when it comes to maintain a specific part of the code ?

Yes ? It's still ours then.
Probably because one or several of the above issues remain.
I used current brain here, because our future brains are no different than other team members wishing to interact with maintainable code.

Conclusion

The reality of projects make things a little less binary than that, obviously, a project's life is full of compromises.
But if we want its life not to end prematurely, we should strive for this maintainability.

Which is the responsibility of the project itself by the way.
Not only us, writing our code. Never only us.
But all other collaborators as well.
I think every collaborator should be seen as temporary (the reasons for their unavailability are actually multiple and not that important when it comes to the project's code).

Our code should belong to the project.
If we want it to be maintainable and qualitative, we need to let it go.

That way, we will reduce the waste of any resources, which is often money but also our sanity and the most valuable resource in our world: time.