The Enterpri[s|c]e Trap

by Andreas Schipplock

The Beginning

In the beginning of the "computer" people were developing with 0s and 1s; really. Then some dude came up with an abstraction which some know as "assembly" which made it easier to write 0s and 1s. Though it's a very old abstraction I myself "developed" in assembly. I did some Microsoft Windows specific applications with 'masm'. I learned assembly in school. At first assembly was like "eh?" but once you understood you could write it like you speak.

But of course writing assembly code needs quite a lot of time. It has some advantages though. First, you really know what you are doing. That sounds like as a matter of course but nowadays this isn't. It has its cons as well. It's very processor and operating system specific. I myself used to write Microsoft Windows applications in masm which is very specific. Rewriting them for Linux would require a complete new implementation (more or less).

People who were used to writing 0s and 1s were afraid of writing assembly because that abstraction only could harm. Of course.

Ritchie Came Up With C

Later on some scientist called Dennis MacAlistair Ritchie invented the C programming language. Together with Brian W. Kernighan he wrote a book which is called "The C Programming Language" and it's a "must buy" imho. Only because it's still valid as of today. C first appeared 43 years ago.

C was another further abstraction and people who adapted to assembly now feared C because now C was evil. But as time went on people adapted to C and C was such a success it's still the most used programming language out there. A programming language that's 43 years old is still used by most of the people. C influenced a lot of other programming languages like C++, Objective-C, D, Go, Rust, Java, Javascript, Limbo, Perl, PHP, Pike etc...

C even turned into some kind of "target". Many new programming languages just "compile" down to C code. Also most tools for linux and unix like operating systems are written in C and you'd rarely find anything that doesn't need a C compiler in the *nix world.

But when you first learn C and don't understand the underlying hardware you'd probably find C "hard" to understand. So one might wonder why it's the most used programming language in the world. I say it's the evolution. Assembly programmers knew what their C programs did. They just understood. And they understood that C is helping them in writing efficient code while still understanding it.

Perhaps C is the best abstraction one needs for a computer. C let's you write structured code that's not too far away from your hardware. You have full control of your hardware and still understand your code because it's structured.

Abstraction Jungle

Still every "new" language wants to abstract further away from the computer which sounds fine for people who don't understand it. But once you have a very specific problem you are left alone with the programming language and its ecosystem; and because you have no clue about your hardware and all the layers you are using blindly, you're lost. I'm not making this up; I experienced this myself. You are working on a pile of layers you don't really understand. You will get the first 80% right and the last 20% horribly wrong. Is that what you want?

What I'm saying here is that most developers don't know what they are actually doing.

A simple task like counting the lines of a text file with 10+ millions of lines in a reasonably short time is a problem for most of the programmers I know. It's not a real allegation but it still frightens me because it is a simple task.

Further abstraction means 100% trust. So why would one need a further abstraction of an abstraction that was far away from the hardware already?

Well, it's the "business" thing. Business obviously doesn't need the last 20%. They are ok with you churning out some code that delivers the 80%. Most of the time it even doesn't matter if you don't understand what you are doing. You are basically just using several libraries with your own logic and see if it works out. You are the "gluer" aka conductor.

The Actual Enterprise Trap

Let's say you need a database because you can't write it yourself. It's a difficult task, right? So it probably makes sense to use something that's proven (I always give that advice, funny, eh?). So you have some choices here. It's often the choice between mysql, mariadb and postgresql because people believe it's "free". I tell you it's not. By using mysql, mariadb or postgresql you depend on them the minute you start to use it. In most cases you won't hit severe problems but I can tell you, at some stage, you will need support. You probably can find a solution using your favourite search engine when someone already faced your problem (which is likely) but if no one ever had your problem, you are lost. No, not really; you can buy "support" from several companies that built their business around mysql, mariadb and postgresql.

Eh? What's wrong here? You started to use something you never understood completely. Most people have no clue what these databases are doing behind the layers you are using and a lot of developers are stating this is the way to go. To have abstractions which implementation you shall not understand. You shall only know the "interface".

This leads to a strange evolvement. People are getting used to the gotchas of these layers without knowing what actually happens behind these layers. This also means that this knowledge can become invalid very quickly if the implementation changes (which is likely).

But people are ok with it. They get all this "enterprise" stuff for "free"; basically to play around on their own. Once they got used to it, they use it for their next product. If that happens, it's likely they are going to sign some contract with some other company which does understand the abstraction (or they are ok with the 80/20 thing).

I only talked about databases, but you can map this on almost anything you find on the "internet". ActiveMQ, Droole, Wildfly, Tomcat, Elasticsearch, solr, etc...just read a bit on and you will be infected with all of it.

It's all there to make you believe it's going to make your "business" easier and cheaper but in the end it's often a pita.

I don't want to trivialize that being a software conductor is wrong. Conducting software is something that obviously needs to be done.

But for me it has a taste I don't really like too much. All the "enterprise" stuff is moving too fast to keep track of all the layers and the implementations underneath. I also talked a lot about hardware but when talking about all these "enterprise" stuff your "interface" is probably just a piece of software.

You are further away from your hardware than you will ever believe because you are used to all this abstraction.


Please don't get me wrong on this enterprise trap. I love proven libraries and I also make use of them. I also make use of MariaDB, because I get a lot of functionality for free but you have to be very careful when choosing 3rd party software or libraries. Only if you understand its implications and only if you have evaluated it long enough you can decide to use it. Make sure you understand that you don't understand. Make sure you are fine for paying a support contract in case your business is serious. Make sure the technology you use doesn't lock you in completely.

Now it's you who decide.

Thank you for reading.

I hope this text was useful.