What the Barbarians may Teach the IT Industry
The word “barbarian” originated in ancient Greece, and was initially used to describe all non-Greek-speaking peoples, including Persians, Egyptians, Medes and Phoenicians. The ancient Greek word “bárbaros,” from which it derives, meant “babbler,” and was onomatopoeic: In the Greek ear, speakers of a foreign tongue made unintelligible sounds (“bar bar bar”). Late in the Roman Empire, the word “barbarian” came to refer to all foreigners who lacked Greek and Roman traditions, especially the various tribes and armies putting pressure on Rome’s borders.
Ok, let’s not make ourselves too pedantic. History details are for pedants, academics and script writers. What’s more important is THE lesson.
Of course, there’s no analogy of the Roman empire in the IT industry except perhaps the Windows desktop empire. But we are not here to talk about toppling Windows desktop or the ludicrous Apple empire.
We are not here to preach to the choir.
We are here to talk about what ITMarketplace believes in.
This is not the story about the glory of Rome, it’s the story of millions who rise and fight for freedom against the tyranny of supposed thought leaders and bureaucratic corporate enterprise who are nothing but scammers and schemers.
To quote The Joker:
You know…they’re schemers. Schemers trying to control their little worlds. I’m not a schemer. I try to show the schemers how pathetic their attempts to control things really are.
Each community has their own point of view. Each has their own idiosyncracies, culture and identity that separate one from the other. We are not here to shove what we believe in down your throat.
We are not here to put a stake and burn the heretics.
The IT industry has no parallel of one big empire like the Roman’s. Instead, we would like to list a lot of different empires (or viewpoints) that need to be toppled before it spreads like a cancer. Oh, cancer is a strong word. If you like me to be benign, let’s just say I want these empires to decrease and eventually sunset its existence.
The Empires are Crumbling
1. Java
Java is a time sink. It is verbose and robs you of productivity. You may list a lot of great software that is written in Java but you can have better alternatives, because Java is just one front-end language (among many) to the underlying runtime software which is the JVM (Java Virtual Machine).
If you want to use JVM, be my guest. I have a lot of respect for the JVM. However, you are better off with its functional programming cousins like Scala, Clojure or the like.
The keyword here is functional programming.
2. Frameworks
I have already railed against frameworks here. Of course, you cannot control the tide. You cannot control the ocean. Heck, it is “anything goes”. This is when human nature is set loose and you are in for the wild party. Granted, you cannot control humans’ way of expressing themselves. It is apparent with JavaScript. It is ubiquitous in all programming languages.
The problem is not the proliferation of API.
The problem is the lack of appreciation for protocols.
To quote Jesper Louis Andersen,
Protocols are far better than APIs because they invite multiple competing implementations of the same thing. They debug themselves over time by virtue of non-interaction between peers. And they open up the design space, rather than closing it down. In a distributed world, we should not be slaves to API designs by large mega-corporations, but be masters of the protocols.
You see, when humans are more aware of different messaging protocols like ZeroMQ, NATS, Project Iris or whatnot, you can bridge all those isolated islands of APIs and make the world a better one.
I’d say it again. It is not a problem of APIs but you can read the case against frameworks here.
3. Microservices Mania
Oh, here we are again. The next iteration of SOA is just another new name. It’s the same old dog but in a different clothing. What else is new?
Are you going to program microservices using your favorite interpreted language? What’s not to like?
Make no mistake about it. Interpreted languages are great but those are not suitable for microservices. Granted, there are containers so you can wrap around your language runtime and the associated script.
But here’s the rub.
Interpreted languages were created for single node (physical or virtual machine). In the new era of containers, containers come and go. They are immutable. They may be transient or long-running but that doesn’t change the fact that you still include a hefty OS image when you use an interpreted language in your container.
In this case, you are better off using a compiled language for microservices.
The deployment of a single binary is a usability win. When usability wins, you are being agile without being a disciple of a devil called Agile Manifesto!
Again, before you mistake that I’m against microservices, I’m not.
Just don’t use an interpreted language to implement a microservice in a container. Containers are meant to move to and fro. The heavy luggage (or should I say baggage) of interpreted language runtime defeats the very purpose and mobility of containers.
Containers are more about business logic than data.
Interpreted languages are better suited for analytics, one-off queries like MapReduce, OLAP and the like where you move data, not logic.
So what are the implications of using microservices?
- With small services, you are left to develop a program, not software. Software is being developed by teams of developers. You are not a software developer. You are an application programmer
- That means, to debug a program, you have minimal unit testing. Don’t delude yourself into using continuous integration (unless you are debugging software).
- That is, unit testing is to program what continuous integration is to software
- Microservices spell the doom of monolithic enterprise software. You won’t gain the benefits of microservices if you are still stuck in piles and piles of code. There is a reason why they are called microservices. They are small which means they are relatively easier to debug than software
- Microservices imply the proliferation of average Joe developers writing small programs to meet business requirements while the rockstars (ninjas, cream of the crop, euphemism intended) develop distributed system software
4. Agile Manifesto
Let Zed Shaw do the talking instead. This is just one case of “anything goes” in the IT industry. The Agile Manifesto must be burned to the ground until its ashes are no more.
Programming, Motherfucker
Do you speak it?
We are a community of motherfucking programmers who have been humiliated by software development methodologies for years.
We are tired of XP, Scrum, Kanban, Waterfall, Software Craftsmanship (aka XP-Lite) and anything else getting in the way of…Programming, Motherfucker.
We are tired of being told we’re autistic idiots who need to be manipulated to work in a Forced Pair Programming chain gang without any time to be creative because none of the 10 managers on the project can do… Programming, Motherfucker.
We must destroy these methodologies that get in the way of…Programming, Motherfucker.
5. DevOps Mania
The DevOps mania is the continuation of the class-based OOP scam. It started where the Agile Manifesto ends.
I have said in my previous post that there is no such thing as a full-stack developer, let alone a DevOps!
This perpetuation of DevOps myth is not only destructive but a form of mind conditioning that is tantamount to abuse. It is not only toxic to the individual but to the IT industry at large.
Make no mistake about it.
I am not against the principles of DevOps, only its demarcation.
That is, you are either a developer or an ops but not BOTH.
6. Complicated Syndrome
This concludes the list of empires that need to be brought down if we are going to sustain a healthy and competitive IT industry.
This industry has toxic obsession for making things complicated in part because the industry players want you to lock in to their complicated workflow or process.
The antidote to this is open source software.
However, just because it is open source does not make it open or transparent. Just because Docker is open source does not make it accessible to average Joe. Infrastructure software is complex because it tackles a really complex problem.
But complex != complicated.
Complexity is to engines what complicated is to humans.
If your user interface is cluttered, remove unnecessary parts.
If it is not necessary, remove it. Design ruthlessly unless there is nothing more to be removed. Design ruthlessly from idea to implementation. It never ends.
Do you want to be a developer, and sustain a fun and meaningful IT Marketplace? Just click HERE.
