More means more can break

Last Update: 15.10.2018. By Jens in Newsletter

I know our society and also our dev world loves more. More CPU, more RAM, more Services, more Layers, more X. But that more is not always good. Maybe we can even argue if it is good at all, but not in today’s mail.

For now, it is layers, processes, services.

On Friday I was analyzing a problem in an import process of an older application; another one from the stone age. Anyways, what is basically does is downloading a CSV file from a remote host (B) and then importing the data of it into a system, let’s call it A. Sounds easy, right?

And it could be. But guess what, it is not. If devs can make it more complex, they will do :-)

On one preprod server P1 of that system A runs a cronjob, which will run once a day and download the file from host C. On C runs also a cronjob daily, which will download the file from the final host B. The file on B was also placed there by a process that runs once a day. In the end, we have sync three cronjobs.

As I was reengineering that process, because, guess what, the documentation was out of date, I started wondering why C was there at all. It makes no sense from a technical point. It’s just a point a failure more…

Adding more is easy. Code is free. Reducing complexity on the other side is hard.

Aim for the latter anyways :-)

Want content like this in your inbox each workday irregularly? No BS, spam or tricks... just useful content:

I understand and agree to the privacy policy