Understanding the value of software can help us code better
I think this is the best way to implement this, but I'm not sure
One of the constants of software development is decision-making. However, it's not always that clear which decision we should make. That uncertainty can cause us to feel lost and stressed out, and start wondering if we are compromising the quality of our software.
A good strategy we can follow when we're not sure about which decision to make, is to remind ourselves of what really makes our software valuable. If we can keep that in mind, we can better align our decisions to move forward in that direction.
What makes software valuable
Software has no intrinsic value. The value of software comes from the positive impact it has on achieving a particular goal or set of goals. Think of it this way, if the website twitter wasn't ever put into production, but the code was written, would the company twitter be valued at the billion $ mark as it is today? My guess is a big no. The twitter website value resides in the revenue it is able to create for its company. If it didn't generate revenue, it would have no value, and the company would probably be out of business by now.
So the question now becomes, what does an app need to do in order for it to achieve the expected goals? From my experience as a project manager, we don't know for sure. In the context of software developed by a company, usually the executives have a faint idea of what the software should do, but it tends to be wrong most of the time. The truth is that it's an exploratory process. We start with those faint ideas and as the software implements those ideas, and we try them on the field, we get a broader view of what steps we should take next. And adjustment by adjustment, change by change, iteration by iteration, we find out what features our software needs to have in order to achieve the goals the company wants.
By keeping in mind that software only has value if it achieves goals, and by looking at the process of discovering what software needs to do, we can infer the properties that makes it valuable. I like to think of them as:
- Correctness
- Maintainability
Correctness
Correctness can be expressed by answering the question "Does this software fill the requirements we think need to be filled in order to achieve our goals?". If the answer is yes, then the software is correct.
The requirements can go from very domain specific, like adding or removing a To-Do from a list if we're making a to-do app, to more generic requirements, such as performance and browsers support.
Initially, I believed that correctness concerns should always trump maintainability concerns. Nowadays, I'm not so sure. While I still keep the belief that correctness should come first most of the time, there might be situations where fulfilling a given requirement puts such a burden in the software maintainability, that we might be better off trying to get rid of the requirement and finding a new one that may achieve the purposed goal.
Maintainability
Maintainability refers to the capacity the software has to adapt to the changing requirements. In other words, we can consider that a piece of software is maintainable if, as time goes by, the cost of adding, removing or changing features does not increase.
Given the process of finding out requirements, we can expect that a piece of software will have to change a lot. And Keep in mind that requirements are ever-changing. Their volatility may decrease as time goes by, but due to the impermanence of our world, they will never be fully stable. Therefore, it is vital for software to be capable of adapting to changes. Otherwise, there will be a day when it will lose its correctness and become worthless.
Making a decision
Next time we have to make a decision on our code base, let's remember that correctness and maintainability are what make software valuable. Therefore, every decision we make should either make our code base closer to filling the requirements and/or make it more adaptable to the future.
When in doubt between two seemingly good enough approaches, we should just choose one. It probably won't matter, and if it does, the faster we move the sooner we'll find out.
It's usually pretty easy to find out if our software is correct or not. But knowing if it is maintainable or not, tends to be not that straight forward. If you'd like to know a strategy that will help you make your code more maintainable, you might find this article interesting.