The idea and concept of standards is great it is just incredibly boring and not interesting to talk about. This sounds like a conversation with your doctor about taking medicine. I should be doing it but it is not something that excites or drives me. It is easy for others to see the need and suggest it. Ultimately as a goal or a mantra I do not want to keep having the discussion about should we or should we not have standards. If your group has no standards then their standard is no standards.
When software engineers hear they must stick to the standards what they hear is, “We’ve chosen your stack for you and we do not care about your usecase.” This is not particularly true but there needs to be give and take in the journey towards standardization. If we only focus on the destination of what those standards are we will waste time and not sell our use case. We should not have to have many meetings and discussions about why standardization is good. Software Engineers just like anyone else in the business is looking for what is going to add value. For a software engineer any automation or tools that allow them to focus on the challenges of solving hard technical problems for the business will win by default. If the tools are providing this value then they will sell themselves. Ultimately software engineers want to be able to release the safety valve of standardization when a problem the business faces is a key differentiator and diverging from standards is more than worth it. In general most problems software engineers face are as Amazon has called “undifferentiated heavy lifting”.
When the foundation is laid standards sell themselves through tooling and toolchains. If a standard set of boring technologies can help get my project out the door a week earlier it is a no brainer. This flow reminds me of whether I would choose a streaming video service or pirating a video. Why would I go out of my way when I can pay the small fee to stream video extremely conveniently. Standards sound boring but they are choice accelerators. If we all come together on a set of technologies that are reliable we can move on the the more interesting challenges.
Developers want to be experts in the chosen set of technologies and have the reasons provided why those technologies were chosen. What were the use cases they shined in? Where did competitors fall short? Why would I choose one over the other. We do not want to set the image that our chosen technologies are small because we are afraid of considering new technologies and are not learning. We want heuristics and weighing of each and every new technology and why they are being considered or not considered.
There are newer and more expansive sets of technology each day and we have a limited amount of time to analyze and learn each one. If we categorize the concerns of something like the goals of a database we can approach the vast array of these choices and select a few. Here is our choice RMDBs, NoSQL, Analytics Columnar store, etc etc. These are the use cases we commonly see. If you have a different use cases let’s talk about it but if sounds like these other solutions let’s start there until we need to reevaluate. This demonstrates your org is not afraid of embracing new ideas, you know someone needs to operate and maintain these solutions and it is not just the devs doing this, and you start becoming an opinionated engineering organization with technical chops on how you settle on your technical choices.
Do not focus on just the destination, train and converse with your team about the benefits and allow your team to reap those benefits. Automate your tooling as soon as possible. As soon teams start leveraging templates to start up new projects strife about “should we standardize?” goes away. Did your team find a key differentiator that your standards do not facilitate then start evaluating what you can buy off the shelf or find from a managed provider before building it yourself.
If you’re interested in Veterans United Home Loans check us out here