Normally I describe bad APIs as looking like they were written by a committee of drunken orangutans.
This thing makes the output of a committee of drunken orangutans look like art.
Wtf did I just read? This is in another league of bad APIs.
I've been pulling my hair out with the totally unrelated but also awful Marketing Cloud (owned by Salesforce). This article made me feel better.
Have read this yet, but I’ll absolutely give a +1 for the “fuck marketing cloud” sentiment. It’s like Salesforce bought it, then gave up on it.
Had to contact support this week because (on top of an already infuriating week of marketing cloud bullcrap) an exit criteria in Journey Builder was firing when it shouldn't. Basically amounted to a string comparison of A = B? But one was from Contact Data and the other from Journey Data. And you know what their response was? "Yeah.. that won't work, you have to do B = A". I kid you not. What's worse is that actually fixed it! What a joke of a platform. How shit do you have to be at coding to end up making a string comparison non-commutative? Like..I don't even know how you'd screw up that badly accidentally. It's a veritable kaleidoscope of shitty infuriating bugs.
If B=A, why would you ever think A=B?! Learn your logic, man! That’s on you.
Really though, the structure for the program is just so aggravating. I’m a Pardot man myself. (Sorry. “Marketing Cloud Account Engagement.”) Every time I try to get a client to go with it, the AE’s jump in and desperately try to throw in Mobile Studio and everything else Marketing Cloud. I always go back to the client behind the scenes and warn them that if they go that route, I won’t set it up. It’s not worth the pain.
Beautiful.
The API is bad, I get it. But the author also seems a little too aggressive with the "my way is the best way" attitude.
Curiously "my way is the best way" is (IMHO) the greatest cause of problems at the design and architecture level in the Programming World.
I've worked for almost 2 decades as a freelance designer-developer (aka contractor) across various industries and even languages and frameworks (all the way from server-side Java to web interfaces and iOS applications) and one quite common scenario was me being hired because some piece of software was pretty much unmaintainable, and that was almost invariably that either a single designer-developer did the whole thing themselves during their oh-so-special learning stage were they've just learned software design and overengineer everything (in OO that usually means things such as totally unecessary, all the time, use of design patterns and inheritance for stuff were there is always and only 1 implementer) or 3+ people simultaneously or over the years who each got responsability for that software or part of it and decided "I know best" and proceeded to add a whole new layer with a different software design strategy, coding standard and sometimes even a different language, the result after a few of those being pretty much spaghetti code AND design and some of the most "interesting" bugs you can imagine (due to mismatching assumptions between layers).
By the way, you do notice exactly that kind of crap coming out as APIs and Frameworks from the kind of companies (*cough* Google *cough*) whose idea of Technical Architect is somebody with 8+ years experience and who never worked elsewhere: notice how the Android stuff has had various strategies for doing the same thing over the years, the API has grown over time massivelly (it was already too big and messy to begin with), there's code-generators in the IDE to try and cover the gaps between newer techniques and older ones and they've even introduced a new language half-way for no actual architectural advantage (the pinacle of "I know best" "genious" is making your own language).
Personally during my time as Technical Lead I used to hire people very much based on "have you ever worked on a project over its entire life-cycle?!" because those burned by their own ignorant-yet-pretentious stage are the ones who get it that Ego is less important that pretty much everything else in making software and I firmly believe that "having seen and having had to maintain the results of your own fuckups" should be a requirement for anybody designing an API or Framework.
well summarized write up.
I am working on a 50 year old codebase which little documentation since "tHe COdE iS tHe ManUaL"...
its in the academic field although this does not mean that people took care about it.
and due to porting to newer language styles this thing is near impossible to get into.
I understand that times have changed much.
however to maintain this stuff progress has to be put on halt until a system is established to clean up this mess of 30 years of spaghetti code (assuming for 20 years it was alright)
Im not even 100% sure that API is really bad? Some hairness could be easily explained by performance reasons. You don't want logging to take a massive amount of system resources.
Yeah, it is really bad. And lazy. The kind of bad that people who don’t take pride in their work do. The kind of bad that makes great programmers quit
This is one of my favorite humorous articles about programming! Love it.
I was not expecting a rabbit hole that deep. Who underwrite that api for shipping?
Normally I describe bad APIs as looking like they were written by a committee of drunken orangutans.
This thing makes the output of a committee of drunken orangutans look like art.
Wtf did I just read? This is in another league of bad APIs.
I've been pulling my hair out with the totally unrelated but also awful Marketing Cloud (owned by Salesforce). This article made me feel better.
Have read this yet, but I’ll absolutely give a +1 for the “fuck marketing cloud” sentiment. It’s like Salesforce bought it, then gave up on it.
Had to contact support this week because (on top of an already infuriating week of marketing cloud bullcrap) an exit criteria in Journey Builder was firing when it shouldn't. Basically amounted to a string comparison of A = B? But one was from Contact Data and the other from Journey Data. And you know what their response was? "Yeah.. that won't work, you have to do B = A". I kid you not. What's worse is that actually fixed it! What a joke of a platform. How shit do you have to be at coding to end up making a string comparison non-commutative? Like..I don't even know how you'd screw up that badly accidentally. It's a veritable kaleidoscope of shitty infuriating bugs.
If B=A, why would you ever think A=B?! Learn your logic, man! That’s on you.
Really though, the structure for the program is just so aggravating. I’m a Pardot man myself. (Sorry. “Marketing Cloud Account Engagement.”) Every time I try to get a client to go with it, the AE’s jump in and desperately try to throw in Mobile Studio and everything else Marketing Cloud. I always go back to the client behind the scenes and warn them that if they go that route, I won’t set it up. It’s not worth the pain.
Beautiful.
The API is bad, I get it. But the author also seems a little too aggressive with the "my way is the best way" attitude.
Curiously "my way is the best way" is (IMHO) the greatest cause of problems at the design and architecture level in the Programming World.
I've worked for almost 2 decades as a freelance designer-developer (aka contractor) across various industries and even languages and frameworks (all the way from server-side Java to web interfaces and iOS applications) and one quite common scenario was me being hired because some piece of software was pretty much unmaintainable, and that was almost invariably that either a single designer-developer did the whole thing themselves during their oh-so-special learning stage were they've just learned software design and overengineer everything (in OO that usually means things such as totally unecessary, all the time, use of design patterns and inheritance for stuff were there is always and only 1 implementer) or 3+ people simultaneously or over the years who each got responsability for that software or part of it and decided "I know best" and proceeded to add a whole new layer with a different software design strategy, coding standard and sometimes even a different language, the result after a few of those being pretty much spaghetti code AND design and some of the most "interesting" bugs you can imagine (due to mismatching assumptions between layers).
By the way, you do notice exactly that kind of crap coming out as APIs and Frameworks from the kind of companies (*cough* Google *cough*) whose idea of Technical Architect is somebody with 8+ years experience and who never worked elsewhere: notice how the Android stuff has had various strategies for doing the same thing over the years, the API has grown over time massivelly (it was already too big and messy to begin with), there's code-generators in the IDE to try and cover the gaps between newer techniques and older ones and they've even introduced a new language half-way for no actual architectural advantage (the pinacle of "I know best" "genious" is making your own language).
Personally during my time as Technical Lead I used to hire people very much based on "have you ever worked on a project over its entire life-cycle?!" because those burned by their own ignorant-yet-pretentious stage are the ones who get it that Ego is less important that pretty much everything else in making software and I firmly believe that "having seen and having had to maintain the results of your own fuckups" should be a requirement for anybody designing an API or Framework.
well summarized write up.
I am working on a 50 year old codebase which little documentation since "tHe COdE iS tHe ManUaL"...
its in the academic field although this does not mean that people took care about it.
and due to porting to newer language styles this thing is near impossible to get into.
I understand that times have changed much.
however to maintain this stuff progress has to be put on halt until a system is established to clean up this mess of 30 years of spaghetti code (assuming for 20 years it was alright)
Im not even 100% sure that API is really bad? Some hairness could be easily explained by performance reasons. You don't want logging to take a massive amount of system resources.
Yeah, it is really bad. And lazy. The kind of bad that people who don’t take pride in their work do. The kind of bad that makes great programmers quit
This is one of my favorite humorous articles about programming! Love it.