A fundamental skill in software development is realising when you have to relinquish control and actually doing it.
Relinquishing control is crucial for delivering the desired results within a given set of physical limits.
For example, you have to deliver a project including the features X, Y, Z, within the deadline which is in 2 weeks, while a workday has 8 hours and you are working in a team of N people. Relinquishing control will get you there.
Why is it a skill though? Relinquishing control requires
- Being aware that you cannot solve every problem you run into and that you can solve even less problems on your own, when you intend to meet quality standards.
- Being ready to compromise, since offloading work to either a person or software will not yield the exact same result that you originally hand in mind.
We’ve all witnessed people having hard time with this:
I won’t give this project to Jane, because she won’t deliver exactly what I have in mind and definitely what I and only I have in mind is important and always right.
or…
We will have to write our own search engine, because our business is so important and unique and Elasticsearch is for the lumpenproletariats.
Holy shit, this makes me sad. It kinda reminds me of my 19 year-old self thinking it was a good idea to rewrite SourceLair in pure C. Thankfully this atrocious consideration did not last long.
I got triggered to write this article when I read the announcement of Cloud Native Buildpacks. Buildpacks let developers relinquish even more control about the underlying infrastructure that their applications will run on by embracing programming language specific file system conventions.
I think that’s amazing. Relinquishing control over the implementation of parts of our software to colleagues or third-party software (frameworks or services) lets us focus and polish our work.
That’s it. Trust. Offload. Focus. Deliver!
