Lately, I’ve been struggling at work with a 3 year old React Native project, which kinda fails to work anymore. It is the standard type of spaghetti code on top of last minute features, which eventually leads to a dead end. Add to this the frequency of iterations for React Native itself, which brings breaking changes every few months, and you have the whole, depressing, unpleasant picture. I’ve been making huge efforts to keep it afloat, and resorted to strange workarounds (as a Romanian, I’ve been exposed very early to the concept of “tying it up with a wire, and it will work out, somehow”, a concept so widely applied on my country, that I suspect it’s part of the deep cultural layer).
But, as it was bound to happen for some time, I hit a wall. No matter what I do, no matter what trick I pull out my sleeve, the sheer complexity of the accumulated code makes it impossible for it to work anymore. So, I decided to start clean, from scratch, moving the needle to the current version of React Native, and basically facing upfront the discouraging task of eliminating all that’s not working. All that spaghetti code that’s lying around for years, maybe doing something useful, maybe not.
As I was doing this – with moderate success, to be honest, fingers crossed – I also realized I just found the topic to write about today: managing obsolescence.
When It’s Something Obsolete?
The first answer that comes to my mind is: “well, when it’s not useful anymore, doh!”. But how do you define “useful”? If you’re not using it daily? Monthly? In the last 5 years?
One way to define the amount of usefulness is to presume you are going to need that thing constantly. From this point of view, money or health are never obsolete, for example. You are going to need those two constantly.
But if you really put your mind to it, it seems that you can think of something better than money – like just manifesting everything you want, without an actual exchange, without a transaction. And there is something even better than health, which will be immortality, or the interruption of the constant degradation process we call “getting old”.
The more I think about it, the more I realize that obsolescence is a strange concept. It has less to do with usefulness, and a lot more with agreement and context.
Let me try to explain this, using again software related examples.
If, for instance, we need to build a feature for sending SMS into our app, we will create some sort of package, or library for it. It will imlement the SMS protocol and make sure it does this correctly. But, as time goes by, we realize that a large part of our user base migrated to peer-to-peer communication protocols built over the internet (not GSM), like whatsapp, signal or telegram. So, we build another library or package into our app, which allows our users to communicate, using this new transport layer. At this point, the percentage of users who are still using the SMS library is, let’s say, 5%, everybody else migrated to peer-to-peer over the internet.
So, we can safely label the SMS library as being obsolete.
But, it’s not that something intrinsically in the library is obsolete, it’s still working as it should be, it still sends SMSs. What changes is context – people are using other protocols, and agreement – we agreed we should support those people.
Nothing Is Really Obsolete
Let me tell you a secret. Oh no, I just told it, in the title of the paragraph…
Well, yes, nothing is really obsolete, what makes it seem obsolete, is that we change our perspective. We change our context, we agree to do different things, or to do things differently (which may seem like the same, but it isn’t). And then we don’t find a place anymore in our current environment for that thing, for that opinion, for that value, for that approach.
It’s all about what we agree to do and what context are we in.
Everything else is expendable.
