Complexity
I always tell people that intrinsic complexity of anything can’t be reduced or removed. It can only be moved to a different place.
Use build tools as an example. In the beginning, I used make to build my programs and projects. The make tool itself is quite sophisticated, but I mainly used it so that I didn’t have to re-compile all the source files every time I modified something. Of course, for bigger projects, the makefiles are not easy to maintain. It is still possible, witness how something like gcc was built initially in the late 1980’s. The thing is, when a project gets too big, much more than make is needed. I get that, but I don’t need anything more sophisticated than make.
Get Khun Yee Fung, Ph.D. (Comp. Sci.)’s stories in your inbox
Join Medium for free to get updates from this writer.
When I started using java, I used the ant build tool. Again, I had to manage the library versions, etc. But I knew which library I needed to have to build which system. And I knew and still know exactly what is needed to build any of the systems that I still have deployed. When maven came out, I totally liked the idea. I experimented with it, and then I realized too much is hidden in the dependency graph. I don’t know exactly what is pulled in any more. Sure, I can find out, when I build the final deployment package. But if I could get to that stage, what libraries are used is not very much useful any more. I want to know what is needed before I start compiling.
When docker came out, I played with it. But again, I was not too enthusiastic about what I couldn’t see. And, this is the thing. When you have a few of them, the dependency does not matter. When you have a lot, suddenly, the orchestration itself is absorbing the complexity. Complexity has to go somewhere, but I don’t want it to be on the orchestration stage, where the semantics is now implied. In a program, the semantic is sufficiently explicit that compile-time verification means something. Assuming you are using a static typed language. There is a reason I don’t deploy dynamic typed language programs in production. As scripting languages, they are wonderful. As a running system that can’t go down; and if it did, it had to go back up quickly, they are not the right tool for me. Sure, huge companies can deploy programs written in dynamic typed languages. But I don’t have a huge company. So, even for client side, I use GWT, where the code can be mostly verified in compile time.
With maven, and docker, and other tools like that, if the repository is compromised, shut down, turned into profit centers, well, replacing it is going to be painful. I encountered that when Android lost one of the mot popular repositories. Luckily it was quire early for Android. Imagine maven’s repository is no longer available, or is not freely accessible any more. I will have no issues. I know a lot of people will have huge issues just to build something.
Am I being paranoid? Well if it has happened multiple times for multiple projects (OSS does not mean free as in beer), I am not betting on other people’s goodwill. And again, pinky promises mean absolutely nothing for me.
