Rust is a well known phenomenon, it is the effect of the environmental conditions on the metal objects. Well how does this relate to software? Being aware of these factors can help avoid and mitigate such risks in product development. Also, is there anything as “curing time” in software? Lets find out…

Software may seem like an unchangeable entity once it’s ready. Right, because it’s virtual? By virtual, I mean not having a physical existence / presence. It is virtual but, in its own world it’s real. In the software world it is affected by the elements which exist there.

As it’s virtual, the expectations from it will be unreal as well. Users don’t treat software like the real thing. Example: compare a commission work for carpenter to make a chair against a commissioned work for writing software to do some accounting work. How many times would the customer go back to the carpenter for making modifications to the chair? Unless it’s a poorly built chair which doesn’t work, this will be rare. Mostly, it will be well built to the specs and customer would be reasonably happy. With software it’s quite different, as it’s virtual the raw material, the build effort is invisible. Thus, software always seems to be a work in progress (well there will be terms and definition of done) however, it’s never solid. If you know what I mean - there is no curing time (like adhesive or cement) or time required to let the paint dry. The paint seems always wet and like an oil painting you can paint over, remove paint you can even change the body/shape. It seems to always be in a work in progress state. The problem is that this is not true.

There is a phase when software is moldable and then there is a curing time, after which making changes have an effect on the solidity or robustness of the product. This curing phase may not be a tangible thing. You can get around by ensuring automated test suite passes or good coding practices and other great ideas. However, the vital thing is the knowledge. As soon as the team diverges away from the product the curing process begins. The curing process accelerator is the user of the software. The more software gets consumed, more it gets cured / starts solidifying. Like the Schrödinger’s experiment, the box has been opened, reality has taken over 😊

After this curing phase of the software, I compare its life cycle with a metal product as it exhibits similar traits. Example: A bridge built with iron can corrode / rust due to the water vapour in the air or rain. The elements in software world would be its users, the problem (domain) it’s trying to solve, third party libraries / web services, data storages, web hosts, frameworks, operating systems etc. Unless software is built as a system (including the platform its being run on) these elements are always in play and interact and affect the software. These elements listed above (it’s not a complete list) are independent and have their own life cycles, their current state however, affects the software which is deployed in the field. Example: Users found the software ‘state of the art’ when they first used it, over the years users have evolved by using other software they interact with and their expectations from the deployed software are a lot more than what they were earlier. Here the deployed software remained unchanged but, its functionality seems to have reduced (effectively). Let’s take another example: OS, let’s say the software was built using .Net 3.5 on windows XP, it all was running smoothly, one fine day Microsoft decides its discontinuing XP and thus .Net 3.5. Again, software was unchanged, its environment changed and it has a detrimental effect over it. Similarly, with data storages, third party libraries their dependencies, web services, web hosts. As another example, let’s say there is a new authentication protocol in the market, its adopted like wildfire, all the webservices which your software uses have migrated to that, and would deprecate the old one in some time. The software which is deployed would stop working after the deprecation of the older protocol unless it also uses the new protocol. These are some of the examples of elements which affect the software (that remains unchanged after deployment).

Thus, I put forth a point that software out in the field has wear and tear and needs to be maintained. Like the bridge needs repainting, metal replacements, analysis, reinforcements, software also needs to be analysed for effects of the elements and maintained. It’s possible to keep a software product rust free and performing 100% by frequently monitoring the elements which it interacts with and taking necessary actions.