The only source of knowledge is experience

Category: DevOps

The hidden maintenance cost, bitrot!

Sometimes it is very hard for customers to understand the hidden costs involved when you build custom software. By a hidden cost, I mean a phenomenon that apparently is back in our industry called BitRot.

What is BitRot?

Back in the day, BitRot was caused by the fact that the magnetic media we used to store our computer programs sometimes lost their magnetic information, causing problems reading the data back. With the industry moving to new ways to store data, like solid-state drives, the problem is still there but not predominant visible anymore. We have algorithms stat store our data in such a way the lost data can be recovered, and from an end-user perspective, it seems to have vanished completely.

Data degradation – Wikipedia

Bitrot redefined

So although the original problem has gone more or less away, we are now confronted with a completely new way that bitrot is coming back in our industry. You might disagree with me about reusing the name BitRot for something different, but in essence, the problem we face manifests itself in the exact same way. If we don’t touch the software, we write for even a few weeks, the software deteriorates!

Let me explain what is going on here.

BitRot today is the issue when we don’t touch our software for a few days or weeks, and the software deteriorates caused by a number of sources. Let me share a few of the issues you will face when building software today

New known vulnerabilities

A known vulnerability is some weakness found in the software you wrote or in any software you used to build your application or website that can be exploited by someone. You might think, why would my software all of a sudden become exploitable while I haven’t touched it? This is caused by the fact that attackers become smarter each day. they find new innovative ways to exploit software and since the software that is written often contains tons of code not only written by your own company but also open source components, the chance of your software becoming vulnerable itself is a significant risk. This does not immediately mean your software will be exploited as well, but the likelihood your software becomes exploitable will increase almost every day. This is something that you need to keep track of and you need to make updates or changes to your software to keep up with the current state of the industry. The number of vulnerabilities found is also increasing all the time. You can see how fast this is picking up in the following graph that is published NVD – CVSS Severity Distribution Over Time (nist.gov). I added a capture of the graph you can find there, that shows how many known vulnerabilities are found and that the rate of finding them is constantly increasing.

NVD – CVSS Severity Distribution Over Time (nist.gov)

Updates of used frameworks or packages

Your software is rarely built from scratch. To build software, you will use other software components all the time. Depending on the technology you use to write your programs, you use NuGet packages (.NET), Maven packages (Java), Node Packages (Node/Web Development), RubyGems (Ruby development), etc. These packages are built and maintained by others. and coming back to the previous topic, they also need to maintain their software to keep it free from known vulnerabilities. Also, they want to provide new capabilities and features constantly. This implies those packages will get new versions all the time, and keeping up with those more recent versions is not to take lightly.

Let’s assume you build a simple Hello World web application using .NET 6. and React to give a simple example. You can see the screenshot of what I did to create the application in Visual Studio 2022:

New ASP.NET with React project

Then this will result in the astonishing set of 1,487 Dependencies from the NodeJS ecosystem and 15 more from the .NET ecosystem. Starting with a clean template (I updated everything before I created the application in visual studio), this already resulted in 23 Known Vulnerabilities of which 9 are at the level of High!

Analysis of new project with Dependabot (GitHub)

Updates on compilers and tooling

Then there are the dependencies on Visual Studio 2022, which has updates at least once every month. Then we took a dependency on the .NET framework that is updated at least 1x per year and every two years has a new stable release that is supported for a maximum of 3 years. And finally, we took a dependency on the NodeJS toolset, which is also updated multiple times a year. These tools also tend to make breaking changes. You need to constantly keep them up to date because they can also contain known vulnerabilities that might compromise your development environment!

Newer versions of the languages and frameworks

Finally, there are also dependencies on the languages we used. In this example, I used React which is Javascript/typescript based, and C#10 for the .NET codebase. C# updated on a yearly cycle, and if you look at the versions of Node, then you see you need to update this every six months:

Releases | Node.js (nodejs.org)

Those language and framework updates can be significant if you look at the amount of work involved to actually use the new capabilities. Not using them still makes your codebase deteriorate from a maintainability perspective since the industry is moving on with new ways of utilizing the language and framework features. New team members on a project will have a hard time adapting old programming styles and inefficiencies if you only ensure it compiles.

Conclusion

The software you build is in a constant state of decay, and you need to allocate a significant portion of time to keep things evergreen and up to date. Waiting for your updates will cost you significantly more time than updating constantly. Also, here you see, the adage “if it hurts, do it more often” applies and makes the software delivery cadence more predictable and more secure. So make updating packages, frameworks, and languages part of the standard maintenance cycle!

The real challenge lies in making our customers aware of this problem and finding ways to make them aware they need to maintain software. You can not let software untouched for a few weeks since, in the meanwhile, the software becomes outdated and vulnerable. And last but not least it will become more complicated each day to make it up to date again.

Troubleshooting Appium Tests with a logfile

Sometimes you can run into issues when you run Appium. This can be caused by a driver mismatch or a version upgrade of Appium, or some configuration change on your machine. But how do you figure out what is going wrong?

The best way to troubleshoot is to get your hands on the log file that Appium can produce. But where is it located? That was my major issue when troubleshooting. The log files themselves often contain a ton of good information to help you solve the problem.

How to set up the logfile?

You can get a log file by adding a startup command-line argument and specifying the log location. So when you run your tests from a build or a test in, e.g., Visual Studio, the best way to get your log files consistently is by specifying this in your test setup code.

Most of my time in coding I spend using C#. So when you use the Appium test engine with C# you can use the class ServerBuilder. ServerBuilder has the option to use the .WithLogFile option where you can specify the location of the logfile.

You can write your code as follows to startup your test and always have a log file as part of your test run:

I assume you are using MSTest as the test framework in this code sample since I use the TestContext to obtain a location where I want to have the logfile published.

© 2022 Fluentbytes

Theme by Anders NorenUp ↑