(Like this article? Read more Wednesday Wisdom! No time to read? No worries! This article is also available as a podcast).
Once upon a time, in a small country far, far, away, I worked in an organization that thought it was a good idea to write J2EE applications. I have a strange fondness for things that are needlessly complicated, so obviously I was intrigued by the Java language and specifically its Enterprise Edition. One of the confusing things about J2EE is that it was/is a somewhat weird combination of an architecture specification, an interface (API) specification, and libraries, all based on a particular (but unfortunately not very practical) vision of how the software development lifecycle should work. Because of this complexity, people working with J2EE are continuously confused about which bits are standard, which bits are provided by platforms, and which bits (that everyone relies on) are samples provided by the author(s) as a demo.
Everyone who was using J2EE back in the days made the mistake of using Entity Beans and everyone who was using J2EE then learned the hard way that this was a mistake and so everyone who was using J2EE rewrote their applications to use only Java Server Pages, with maybe a session bean or two thrown in to keep the architects happy.
Remember: Architecture is the art of wasting space.
In said organization, we did our development using Apache Tomcat because it was cheap and good and fast. It did exactly what we needed and it did it well. There was a problem with this choice though, which was that it did not make IBM any money, so obviously that needed to change.
At this point in the story, I need to digress a bit for a related side story: Some years before the events described above, I had introduced this very same organization to the Apache web server because, much like Tomcat, it is cheap and good and fast. This had not been an easy process as I had to battle some FUD, since many people in the organization (including lots of “architects”) were convinced that the Apache web server supported only twelve concurrent users. I never figured out where this myth came from and I must admit that I was somewhat confused about the specificity of the number “12” Why 12? Why not 16? Eventually though, I managed to conquer the FUD and we became happy Apache web server users, replacing some crappy web server the name of which I can fortunately not remember.
A big problem with the Apache web server was that it did not make IBM any money and eventually the IBM sales people convinced the architects that they would be better off with the IBM http server. I pointed out that the IBM http server was “just” Apache httpd, but compiled by IBM and so why switch and pay money? This ran into the “support argument”: If there was a problem with the IBM http server, they could call IBM’s amazing help desk and immediately armies of highly qualified engineers would jump onto their problem and solve it. Or so the story that was sold to them goes.
I countered by offering a comparatively modestly priced support contract and told them they would get the number of my satellite phone and they could call that phone 24x7 and would then directly speak to me, without having to take a bath’let to the first three useless layers of support staff. They looked at me real funny and said: “If we do this, are you going to move to the Bahamas with your satellite phone and laptop and wait for that phone to ring, which might be never?” I said I might, at which point they turned around and bought the IBM http server.
A year later there was a problem with the IBM http server and some shared library called the “Silverstream plugin” (don’t ask). The architects asked me if I could take a look at this problem. In response I asked them if this wasn’t exactly the right time to call in that amazing IBM support they had bought? They looked at me real funny, again (they did that a lot), and so I solved it for them for about 175 guilders (it was an hour of work).
Having learned from the phenomenal success of the Apache web server versus IBM http server decision, the organization opted to shell out a large number of guilders to replace Tomcat with IBM WebSphere, a sprawling enterprise software offering, at the core of which was a J2EE application server we simply called “WebSphere”.
WebSphere is/was large and complicated and we didn’t understand it very well. Consequently, there were a fair number of problems deploying and running our applications and when that happened we were typically lost and confused. When that happened, many conference calls were held. Unfortunately, we steadfastly refused to invest in understanding WebSphere better so we never made any progress in running things more reliably.
At some point, during a conference call about yet another problem that we did not understand and could not debug effectively, I completely lost my cool and wondered out loud why we were being such clowns? Surely, if the stability of our production environment depended on a complicated platform like WebSphere, we really needed to spend time and money ensuring that we knew pretty much everything there was to know about it?
What I didn’t see clearly at that time was that that criticism also reflected back to me. Yes, the organization didn’t know enough about WebSphere, but neither did I. Even though I was not necessarily in favor of using WebSphere, this was the platform that the customer, rightly or wrongly, wanted to use and I should have behaved more professionally and learned about it, thereby increasing the value I could bring to my customer. I was right to be upset about our lack of investment in acquiring WebSphere knowledge, but I was wrong not to jump into that gap and take it upon myself to build up the required knowledge and experience.
WebSphere is mostly gone. At least, it is in my world, though I do not hold it for impossible that there are poor sods out there that still have to run J2EE applications on that godforsaken platform. But obviously there are always new editions of this tale, as new complicated platforms that you really need to understand well in order to keep the bits flowing appear every decade. Kubernetes and the clouds come to mind, but databases and monitoring platforms are also in that category.
If you decide to use particular tools, you are well advised to learn these tools really, really well in order to make sure that you can use them correctly and debug your own problems. Support contracts are one thing, but they only work well if you are a proficient user of the system, as it requires a lot of insight to know which questions to ask, how to ask them, and which behaviors are the problem and which ones are just “working as designed.”
IBM specialized in answering problems with “working as designed”, basically telling you that you were a muppet who didn’t understand their product. One time, when we questioned a particular design choice, they responded with “designed as intended”... :-)
At the micro-level the “Know Your Tools” paradigm also holds for the things that you use on a daily basis, like the Unix (Linux, MacOS) command line. I must honestly admit that I am not entirely sure yet about what I think about the average mastery of the command line because I am often impressed with how much people I work with know, but I am equally often depressed with how little other people I work with seem to know and understand.
The Unix command line is a complicated beast which offers very powerful features that can be used to either get difficult stuff done fast or to wreak unbelievable havoc equally fast (actually, often: Faster). The difference between magic performed and disaster struck often hinges on subtle syntactical elements like a well placed or omitted backslash or the right quotes being used. The shell is not only complicated, it is also subtle and quick to anger.
Given that a lot of workloads run on Linux these days, it seems to me that mastery of the Linux command line environment should be compulsory. This mastery should go beyond simple commands like “cd”, “ls”, and “rm” and should stretch out to developing complex pipelines using filters and of course shell scripts.
One of the things that I am wondering about is where kids learn those skills these days. I used to teach course 51434S (Unix Fundamentals) at Hewlett-Packard Education and there we taught new HP-UX power users and system administrators everything they needed to know about using the command line. But where do people learn that these days? I don’t think universities teach this stuff and even though there are plenty of resources on the Internet, on the whole I find them to be of an introductory nature and none of them lead to the knowledge level and experience that I would find to be a minimum acceptable level for the modern IT professional who is manipulating workloads in the cloud.
I developed my own copy of he Unix Fundamentals course. Quick reader poll, should I turn that into a (free) Udemy course?
I don’t care much what your toolset is, but I do care that you understand your tools in and out. Whether you use vim or Emacs, Perl or Python, Bash or Powershell, I couldn’t care less. Same for MySQL versus PostgreSQL, AWS versus GCP, or WebSphere versus JBoss. But if you want to be effective and professional, you better know your tools well and spend time gaining the required knowledge and experience.
Share this post