Why every company should standardize its IT processes

Let’s say that you’ve hired a contractor to build your dream home. You would expect them to know and apply standards specific to construction. This is what makes them a professional and helps you feel confident in their work. Standards ensure that the materials and construction methods used are of an acceptable level of quality. With standards applied, the result should be a home that functions predictably, and—when there are issues with regular wear and tear—is easy to maintain. 

The same expectations should apply to information technology. It is vital for any company’s IT team to have clear, established standards. But in my career, I’ve seen all too many times how a failure to apply norms results in a sub-par user experience at best, and can crash an entire system at worst. 

As a company grows, a few key standards should be put in place pretty fast, to keep up with IT development. Here are the main areas to focus on. 

Managing change is always a challenge for software developers. We want to continually evolve our APIs, or Application Programming Interfaces, by adding new features and improving older ones. This maintains a competitive edge. On the other hand, we also know that continuity is important, and that any changes should have minimal impact on the user experience. The key here is communication. 

Take, for example, what we developers call breaking changes. A breaking change is just what the name implies: a change in code that could potentially “break” the functionality of an interface. Say I change the name of a request on a login page from “password” to its French translation, “mot de passe”, in the code. Because lines of code are often copied between different pages in a system, every page linked to a line of code with the tag “password” will return an error message when a user tries to log in. 

To avoid this, the best practice is to have standards of communication. Whenever a breaking change is implemented, we must have a clear process for notifying relevant parties. It’s important to announce what the change is so it can be rolled out across the system, what the timeline is for rolling it out, and when previous versions will no longer be supported.

If an elevator was newly installed, and you were told it had never been tested, would you want to take the first ride? Most of us would say no. The same applies to IT. Testing is an essential aspect of quality control standards. It is essential for companies to thoroughly and consistently test any software they develop; this helps them gain their teams’ and clients’ trust in the product. However, it can be quite tempting to reduce testing to a minimum, in order to save time and money.

When we write code for a feature, we must also write a test for it, and this can double the time to deliver the feature. So yes, there is a short-term cost to testing, but we must remember that it pays off in the long-term. A feature is often designed for years to come, and if you’re stuck with one that is faulty because it wasn’t properly tested before roll-out, the costs can be enormous. 

In the corporate world, people often think of security and compliance when they hear the word “standards.” Standards in those realms tend to be static and unchanging. Not so when it comes to information technology. 

Standards in the IT world must have a certain degree of flexibility; they must evolve and are subject to change. Our standards must provide order and clear processes, but they also must be flexible and agile. It’s a fine line to walk, but it’s well worth the effort for the development of quality software that works.