Written by: CTO Martin Søndergaard
DevOps: If you have any experience with coding and were on the IT development team only 5-10 years ago, you will know there were some lucky punches we landed.
And if coding and software programming are not part of your job, I will gladly tell you a little secret: Just a few years ago, it was more luck than design that helped make sure the software released to the users was not chock-full of errors. And this is probably a bit too much of an understatement, since—Heaven be my witness—much of the published software was indeed full of programming errors and often did not anticipate the handling of a number of different user scenarios.
Think about it: a wrong comma or a single missing colon is enough for what would have been a simple code fix to turn into a major system crash that could take many hours to restore. And having to go over 35 pages of code to find a single typo is literally like finding a needle in a haystack.
It is still unclear why it did not get any worse than it did and why users simply did not boycott the IT systems, but let me just say that I am certainly happy that we have since made a step forward.
Coding in the old days
Let me try to outline the programming process, the way it looked in the olden days, or, in other words, around 10 years ago.
Back then, we did not operate according to what eventually became well known as the Scrum methods, but according to the so-called “waterfall model”. This is a model where each stage basically must be completed before the next one can begin.
A classic project therefore consisted of 4 stages:
- Idea/request is formulated and perhaps illustrated
- The programming starts and ends
- The new software is tested
- Feedback is given, which basically starts the process over again
The problem with the old approach is quite simply that it takes far too long to get from idea to finished product and that there are so many things during the programming that can go wrong or simply make no sense to the ultimate users.
Therefore, the vast majority of development teams around the globe have long since said farewell to the waterfall model.
Coding nowadays
Today it is Scrum that has the lead when we talk about programmer workflows.
However, as a matter of fact, Scrum is not good enough, either, if you want to apply a quick and agile approach to development and put out serviceable software on the market faster than your competitors.
And today both the users and the support that will implement the system must be involved in the development from the start.
It is namely of no use to anyone if the developers develop a smart feature in a software item, but when they deliver the new code, they just throw it over the “hedge” to the “operations” team and leave it to them to find out, all on their own, how the hell whole thing adds up.
No, if we want software products and updates that have a high level of user-friendliness and high coding quality from the start, we need a more holistic approach to software development.
DevOps: The answer to how you deliver high quality again and again and again
It might sound like the name of a Star Wars character, but DevOps (written in Danish) is actually the answer to the question how you as a developer can deliver, time and again, high-quality software that users find easy to use and that is launched and implemented without a hitch.
DevOps is namely the designation of a workflow, where the launch, for example, of a software update is incorporated into the development work from the outset.
Unlike in the past, the idea of DevOps is based on the possibility to implement every little piece of code that is written directly in a Live system and see it work immediately.
This means that the waiting—often for months on end—in the past for the programmers to finish with the entire code is reduced and replaced with a scheme, where programmers can publish, every day at closing time, the code they have written on that day, and then the functionality is actually available to the users.
Of course, it does not work exactly like this, but, as a general rule, it can be made to.
Quality despite high speed?
The reason why the programming process has become so much faster is that we now use programs that can read the unfinished code and then build the system up as far up as the work has gone.
Let me try to illustrate this with an example.
Imagine you are the illustrator behind the Lego manuals. With the DevOps system, you will be able to press a button, and a system will build up your model as far up as you have reached. If it is a Lego car you are working on, you will therefore be able to test if the doors can open even if you have not drawn up—nor written the code for—the function of the wheels.
Things are very much the same with the DevOps programming. In other words, there will be a live version of the code that you managed to write every day.
Automated tests provide consistent coding quality
The possibility to be presented visually with what you are doing is not the only smart thing about this form of software programming.
No, the smart thing is also that by building the system “on the fly”, you can also set up automated tests that prevent any programming errors in the piece of code you are working on.
In other words, you can set up a few mechanisms that check if what you expect to happen also actually happens. In other words, in somewhat simplified terms, when I press this button, does the right screen pop up?
If so, the code passes the test, and if not, the programmer is notified immediately that there is an error in the code as well as where exactly the error occurs.
This type of automated test flows are an essential part of the entire DevOps philosophy, as it is in these tests that we find out if the software update we are developing actually can also be implemented in the systems without any concomitant problems.
And—to tie it up nicely with the introduction—this is also the reason why we are able to deliver software of a far better quality and with far fewer errors today than just a couple of years ago.
User checks guarantee serviceable solutions
It is naturally part of the story that the thorough testing of our software does not end with several automated tests and simulations. Before new updates go live, they naturally pass through a test group of actual users, who provide feedback on how the system works and if it actually works as intended.
Even if updates must necessarily pass a human user test, speed and quality are, nevertheless, far better, simply because the users can focus on testing user-friendliness and checking if the right features are included rather than on making sure that the programming itself works.
Thus, in the final analysis, this means that we, time and again, are capable of delivering sophisticated software solutions and updates that not only work, but also solve user needs in the most optimal manner possible.
