Modern face of 10 old-school IT rules

IT industry is a living being, as it grows and evolves to meet the needs of fast-paced business of the 21st century. However, despite being largely adjusted, these 10 old-school IT rules still apply.

IT industry today is full of young people with flashing eyes that speak of Agile software development, DevOps workflows, test-driven development (TDD), Docker containers, immutable infrastructure, Big Data analytics, machine learning models, the Internet of Things, Spark, React Native and other buzzwords. They know little about (and seldom meet) the old-school system administrators who worked under Waterfall model, wrote bash scripts, and had to fight the constraints of primitive development tools, many of which they wrote themselves.

However, if modern developers want to deliver top-notch product and succeed, they have to apply the same best practices of software development these old-school programmers had to follow. These IT rules remain unchanged, though they have evolved together with the industry.Here are 10 old-school IT rules, written in sleepless nights and countless liters of coffee; the rules that ensure high quality of software product, smooth workflow and business success:

1. Open-source products are as good as proprietary; quite often they are better
2. To ensure the security of the software, keep the hardware safe
3. The secure product is more important than a secure workplace
4. Automated tests should be written prior to the code itself. Test often, test a lot, test in the cloud
5. There should be a strict control of production environment updates. And a recovery plan
6. Be Agile, iterate and interact with the team and the customer
7. The team is the main asset of any business; learn to be a part of it
8. Integral software ecosystems are superior to disparate islands with automated updates along the links
9. IT department should suggest and discuss, not silently follow orders.
10. IT team is the main driver of change throughout the whole business

We’ll briefly explain what these rules mean to us and, maybe, they mean the same to you.

Open-source products are as good as proprietary; quite often they are better

In the days of old, the developers had to opt for one or the other from quite a limited range of proprietary software development tools to leverage its benefits and embrace its limitations. If the chosen technology was not able to provide certain functionality, the developers had to code the custom solutions themselves or search for third-party modules, add-ons, and plugins. Nowadays, there is a huge variety of various platforms, frameworks and readymade tools for doing literally any task a developer might need, the most popular of them often being open-source and having huge and passionate communities behind them.

To ensure the security of the software, keep the hardware safe

Before the cloud era, this has meant ensuring strong physical protection for on-prem server rooms or renting equipment from top-tier dedicated data centers. Nowadays, this means opting for the cloud offers of trustworthy providers like GCP, Azure or AWS and using their security features to the full extent. Such approach guarantees both the security of the physical equipment located in the highly-protected tier 4 cloud data centers in the US and the EU, and the continuity of the software development and service delivery pipelines.

The secure product is more important than a secure workplace

A couple of decades ago the security threats were mostly physical and originated from the inadequate protection of the connections between the systems. Thus said, the need for limited user rights and firewalls was obvious. Nowadays, with nearly omnipresent SSL and corporate security practices, the main danger comes from the code flaws itself, like the recently discovered Meltdown and Spectre. Thus said, writing a secure code is much more important than configuring a secure workplace nowadays.

Automated tests should be written prior to the code itself. Test often, test a lot, test in the cloud

Shifting the testing process to the left (to the very beginning of the software development lifecycle) allows dramatically shortening the time and effort required for bug fixing in the long run, not to mention the ability to weave the security requirements into the code from the get-go. Writing automated tests and pushing them to the cloud allows creating a continuous integration / continuous delivery workflow, where new batches of code are pushed to the build, testing and production environments automatically.

There should be a strict control of production environment updates. And a recovery plan

Some time ago there had to be a strict process of pushing the updates to the production (with checklists and multiple approval levels) in order to minimize the human errors. Nowadays, automated software delivery pipelines make the process streamline and error-proof. If the tests pass the new code is pushed to production with rolling updates, if the tests fail — smart alerts are raised. Cloud makes doing this so much easier. However, regular backups are needed in case a rollback is still required.

Be Agile, iterate and interact with the team and the customer

Development is not about following the book of rules in the process, it’s about making a working product in the end. Waterfall failed because neither product owners, nor project managers could write 30 pages of absolutely correct specifications mentioning literally EVERYTHING the product must do and how it should do it. The Agile methodology helped introduce iterations and interactions into the field, so the developers and the product owners communicate and collaborate to get the job done in small iterative steps.

The team is the main asset of any business; learn to be a part of it

This cannot be emphasized enough. Today’s business is not a group of departments with siloed tasks, tools and projects that barely talk to each other in the canteen. Efficient businesses of today are cross-functional teams that follow the DevOps culture. They communicate and collaborate a lot with their colleagues and customers in order to get the job done. Relationships precede projects and outlast payments. In the end, the team is what makes or breaks the business, and it’s the main asset of any company.

Integral software ecosystems are superior to disparate islands with automated updates along the links

Enabling all the software in your ecosystem to interoperate is essential for building streamlined workflows. However, the software is so various nowadays that there is no humane possibility to provide an out-of-the-box compatibility for any product with any other product. The only way of doing so is building the software in the form of microservices that talk to each other via APIs. When there is a centralized message broker that helps various modules communicate and interact with each other, the questions (and problems) of data synchronization are gone for good.

IT department should suggest and discuss, not silently follow orders

When the task is set it’s up to the IT department to accomplish it, yet sometimes the team finds the proposed approach suboptimal or the tooling inadequate. The major mistake is trying to solve the issue with overtime work or providing an interim solution and polishing it afterward. The IT team should be ready and willing to say when certain technological advancements, like the cloud transition, have to take place in order to make the task doable.

IT team is the main driver of change throughout the whole business

Technological leadership is essential to help the business thrive, but the sales, the billing or the managerial suite of the company are often not too tech savvy to acknowledge they are not using the optimal tools or following the best possible practices.

It’s up to the IT department to suggest and discuss the needed changes, like the digital transformation or the transition to DevOps. It’s the task of the CIO to provide the C-suite buy-in and wholehearted support to the initiative, yet it’s still up to the grassroots IT team members to suggest the move in the first place.

Final thoughts on the modern face of 10 old-school IT rules

As you can see, these 10 IT rules are indeed the best practices that apply to any modern business, be it a startup or a full-scale enterprise. After all, IT department exists to support business and make it cost-efficient and competitive, is it not?

What do you think on the topic? Do you consider these IT principles important and follow them? Did we miss anything or should we remove something from the list? Please share your opinions in the comments below!

This story was originally published on my company’s blog — https://itsvit.com/blog/modern-face-of-10-old-school-it-rules/

Modern face of 10 old-school IT rules was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.