A few months ago, I got a job. They pay me and everything! Specifically, they pay me to work on an internal tool for the customer engagement team. This tool is written in Java using the Play! Framework.
I might have more to say about Play in a future post. Then again, I might not. My feelings on it are pretty neutral. It’s an MVC framework. You got your models, you got your views, you got your controllers. It’s more verbose than Rails, being Java, but not hugely so. It’s rather like Django, but with batteries not included. The framework is actually implemented in Scala, and the template language is a weird Scala DSL that compiles to Scala functions that generate HTML. I’m not a huge fan of Scala. I’ve seen some incredibly nice libraries written in it, but you, and by you I mean I, have no chance of writing a library like that, because the implementation of that library is file after file of gobbledegook that looks like the horrific love child of the section of the Java language specification on generics and an academic paper on Hindley-Milner type theory. On the other hand, the arguments to Play templates are statically typed. This is nice, because templates are completely impossible to debug, and that goes double for these ones.
There was a time when Play was the only lean web framework for Java and all the other ones were eldritch monstrosities spawned in the moss-lined cesspits of unknown Kadath, but nowadays it’s a singularly unimpressive piece of work. What I’ve seen of Spring Boot really doesn’t look that bad, for instance. Play does seem more Java 8-ready than most of the other web frameworks, but given how watered down Java 8 turns out to be once you’ve spent a little time with it, I’m not sure how much I really care.
But that wasn’t the point of this little discussion. The tool I work on at my job, which I got, where they pay me, and in return I try not to force push my branch with three dumpy commits into the master branch on their GitHub repo, thereby destroying the entire app, was written by another developer who left the company before I joined. And his code drives me fucking crazy. I mean it. It drives me up the fricking wall. The formatting is a mess. The design is monolithic, impenetrable, and basically impossible to unit test. Some of the methods are 200 lines long. In one place, he checks if a string is empty or contains only whitespace using Apache Commons’s
isNotBlank, while in the next he performs the exact same check using Spring’s
hasText. (If Java had just included basic shit like that in its standard library, this wouldn’t be a problem.) Recently, I had to read the code that implements the tool’s Salesforce integration. While reading this code, I felt myself succumbing to the madness of the moss-lined cesspits of unknown Kadath. I started to jump at small noises, like the ringing of telephones or the questioning of dev-ops. When I came upon a coworker in the halls, I would low like a moose calf, or yap like an arctic fox, such was my shock at the sight of another being. I covered pages and pages with diagrams and flowcharts, trying to make sense of it all, finding clues to the purpose of a method in newspaper obituaries, seeing the organization of a class mirrored in a bowl of quinoa salad, muttering HTTP status codes under my breath.
So I rewrite the code, because it’s been made clear to me that this is now my code, and I can do whatever I want with it as long as the tool continues to work. (Well, the senior developers might protest if I decided to implement my own dialect of APL with an embedded MVC DSL on top of Play and rewrite the entire tool in that. But…but I can refactor all I want…so…so shut up! At least I have a job, where they pay me! They even let me write unit tests! So there!) And every few minutes, as I’m rewriting the code, I think about some future person, looking at this code. It might even be me, in the future. Or it might be some other junior developer who comes in to keep the tool running so our customer success team knows what our customers are up to. And I think about this future developer looking at this code, the very code I’m writing as I think this, and being driven fucking crazy by it.
I can’t even imagine what exactly this future developer will hate about the code I’m writing today. All I know is that he (or she–50/50 by 2020) will hate it. It will drive him/her/it/them fucking insane. He/she/it/they will be madly scribbling on the walls trying to understand this squamous code. Luckily, the walls are IdeaPaint, so they’ll erase. But the pain won’t.
And then, maybe, some day in the even further future, a further future developer will read the future developer’s code, and it will drive them fucking crazy. Even their genetically enhanced cyborg brain won’t be able to penetrate such code. It will be like that one episode of Star Trek: The Next Generation where Data came up with a plan to kill the entire Borg Collective by making them look at a really weird shape that would blow their minds, man.
It’s all part of a great circle of crappy code. Simple, crappy code becomes complex, crappy code becomes complicated crappy code becomes simple crappy code again, and at each step, a developer’s mind is lost. Someone has to break the circle of crappy code. They have to write good code. They have to rewrite the entire app in Yesod. Only then will the clouds part, and the darkness pass, and the compiler sing, and the tail calls be optimized, and the gods smile upon this little blue binary. Only then will the circle be broken.
Actually, it will probably still be crap.