Bharatvaj Hemanth
Septemper 1, 2023
Fidelity of a software is the faithfulness of a software to it's goal. If a software gets advertised as a duck, it is expected to move like a duck and quack like a duck, but how do you gurantee fidility when a product is constantly changing due to customer demand?
UNIX programs such as ls, cd and make have perfect software fidelity. The 'ls' command for instance prints out the contents of the working directory to this day as it did 50 years ago and I'm pretty sure if someone 200 years from now tries it, it's going to do the same. But SaaS is a whole another can of worms.
With SaaS due to the quick deployment time, every new version introduces features and bugs both the user and developer has to deal with. Every version slowly erodes the purpose and original intent of the software as it evolves. It's alive.
My idea of software quality is based on how quickly it lets me do my work and lets me get back to real life. And most SaaS software has never been my idea of quality because
But most of my complaints about SaaS are implementation problems. SaaS as an idea, has a redeemable characteristic which I've started valuing as a user. As a model, it provides the most convenience to the majority of people.
An interesting question remains. Can one achieve the software fidelity of simple UNIX programs with SaaS? Yes. Well, maybe.
To improve software fidelity, we need to manage entropy one way or the other. We need to predict some of the pathways software may take during development.
Entropy - the randomness, a closed system can attain over time.
Reversing entropy in real life is close to impossible. In essence, we cannot reduce entropy without travelling back in time. But hey, software is not in the physical realm! There are some general enough solutions we can adapt, that we can use to manage software entropy when creating new software or when working on an existing one.
Non-Goals Having goals is essential to any codebase but there is something we miss to formalize that is equally essential, "Non-goals".
Without non-goals we are opening ourselves to features that are "cute" to have. These things open a door to "feature creep" and they are worse than the tribbles on a star ship.
Software can become increasingly unusable if it has too much feature creep, even if it doesn't directly contradict with the goals of the software. Adobe PDF reader is one popular software that has this characteristic of unusability even though it can properly open a PDF.
Conventions When we are faced with a decision, it is almost always better to take a decision that builds on convention, if the weights of these decisions are more or less the same. There are already way too many "disruptive" things. There are already way too many languages, frameworks, methodologies to achieve the same thing.
If you wake up one day and decide you are going to disruptive anyway, remember that the only thing you can do to be disruptive is not to be disruptive.
Refactoring It is said that, "Every software grows complex enough to handle mail". This was in the 90's. We are way beyond mail at this point. These days it is, "Every software grows complex enough to handle AI".
Whether this is good or bad is a different discussion altogether, but to deliver software as a service, we need to be constantly changing to provide the service as best as possible. When the intent of a program is no longer the same, it definitely calls for a refactor. Using the same architecture even after the original goal is changed, is a recipe for disaster.
Logistics Logistics are an important part in software, especially if we are targeting multiple platforms. Whenever I had to intervene to make a codebase run, I cringe a little and my soul gets a little bruised.
Even physical packages are automated in warehouses of Amazon using machines. Why not software packages? When the logistics are smooth, our operations are smoother. It lets us make make mistakes quicker and recover faster.
Using the right paradigm I am recovering OOP fanatic. If you asked me to do something(anything) two years ago, I would pull out my flashy UML editor and draw classes and interfaces until everything felt right(it never does). I considered using static methods in classes a sacrilege and was resistant to use anything other than the established GOF design patterns, even for the simplest of programs. This can get out of hand, and can become a blocker for productive work.
Point of the matter is that there is no one language or paradigm that is too old or too new, we must use any tool or paradigm that doesn't make us fight to achieve our goal or non-goal.
TL;DR If you have read this far, you may have found that there is a common theme.
The best code you can ever write is no code at all.
And (most) things that doesn't let you write code, or allows you to delete more code, improves fidelity.