There Is No Right or Wrong
From Programmer 97-things
It can be hard to consistently make the right decision. Throughout each and every day we as programmers are faced with decisions: design, implementation, style, names, behavior, relationships, abstraction, .... The list goes on and is unique for each of us.
As software developers, our goal is to produce working code that contributes to a software system or application. How we get to that working system will take one of many possible paths. On this journey to production-ready code, any number of the decisions that you will make along the way can be made differently to send you down a different path. So how is it that we can say that there is a right path and a wrong path to write some method, or that there is a right and a wrong framework, or even a right and a wrong language?
The answer, for almost anything in software development, is that there is no right or wrong path. There is no wrong variable name or naming convention. There is no wrong build or dependency management tool. And there is certainly no wrong language. There are, however, better ways and worse ways. That is to say, there are some decisions that you make along the way that will make your software better, and some decisions that will make it worse. But better and worse in what way?
Better and worse are subjective terms. They are biased opinions that an individual perceives based on past experience, emotion, beliefs, and sometimes ignorance. Objectively, however, better software is generally
- Easier to modify, whether changing existing code, removing deprecated code, or adding new code.
- More reliable with less down time and a higher degree of predictability.
- Easier to read and to understand.
- Able to provide better performance while using fewer resources.
These are facets of your software that you affect with every decision that you make. These goals are what you strive to achieve with each and every decision that you make.
So the next time you are faced with making a decision, try your best to understand all of your options. Try to determine how each possible solution will affect these goals and your own unique software goals. Then, don't try to choose the right option, but choose the better option. Similarly, when team members, both past and present, make a decision, try not to judge their decision as right or wrong.
By Mike Nereson
This work is licensed under a Creative Commons Attribution 3