Implicit Hinders Reusability #

When we are writing code, we all tend to want to make one thing do more than one thing because in the moment it just makes sense to have all of that in one place. All those auto loaders,

Look ma’ I just press a button a solve all those problems!

…

For now.

But how about when the inevitable moment comes and your business rules change or an update to the underlying technology you are abstracting changes, or you need to change a service provider, or … and you have to adapt to it?

You have two options, degrading the capabilities of your code by adding conditionals that skip a lot of the steps you have built-in in the first place or a huge refactoring to allow the one thing to do another thing. Deep down, we all know for which one you will actually have time. 

There is a bigger problem than having to fit another use case in a component that was built to do an implicit thing and to do it well, or the time spent refactoring the entire service to be well scoped this time. 

The bigger problem is that you might be unable to do any changes at all because there were other software written on top of your software that took in account all the implicit behaviour and built around it and actually EXPECTS the system to work in this wicked way. 

Well, if you have reached this point there is no other solution than living with because truth be told there are a few moments in the life of a software developer in which trashing an entire system is feasible.

There is hope. Consider the alternative of always building many small building blocks that can be composed as needed and only what is needed of them. It’s true that writing software this way is more tedious and yes you will ship a little bit slower but will will always be able to ship new features instead of new fixes.

Enhancing a small system to be able to do more and more things is much simpler than degrading a big system to fit smaller and smaller use cases.