The Inner Json Effect
thedailywtf.com
thedailywtf.com
Pretty much the only example of code reuse gone well is open-source libraries; and that's because being public forces the code to be documented and free of implicit dependencies. You pretty much never get that with janky internal frameworks and libraries, and they're usually "reusable" and yet replaced next project.
If code could be re-used efficiently, we wouldn't need half as many programmers as we actually legitimately do.
Consider these statements:
* "Tom is a genius", which implies the Tom solution is a trusted asset beyond improvement, doubt, or questioning. It also implies the solutions provided by Tom are golden unimproveable truths.
* The various statements from Scott suggest an indisputable faith in process and convention.
Clearly there are failures at multiple levels here. First of all Tom sounds like a whiny bitch. These personality types are inherently defensive and typically seek to reinforce an individual's position of self triumph in a small pond. Toxic.
Secondly, Scott has a lot of faith in process and conventions. Processes and conventions are the absolute enemy of creativity. I understand processes are necessary to establish a certain level of security, but they more typically exist to satisfy some OCD insanity where there is comfort in doing things in a particular way without consideration for why they are done in that way. Many developers cannot tell the different between security and superficial stupidity. Many technology abstractions enable that stupidity thereby convolute the differences between security and OCD stupid which only enables additional stupidity.
All of the prior mentioned failures are allowed to exist because the management doesn't want to be involved until there is a problem, such as Tom crying. This is called enabling.
Most important of all is that all technology should be questioned, doubted, and challenged. Obviously this sort of continuous improvement is utterly absent, because everybody has a competing agenda.
Please don't generalize my words and don't use them to activate your own prejudice..
Which is?
By the way, I agree completely with the wording "not just take them for granted by faith." It is much more precise and to the point.
> Which is?
A desire to feel offended and outraged?
As a person doesn't need a religion, to act religious; I can be religious about canned goods or martial arts, or perhaps, engineering.
I do agree that using the term "religious people", while the meaning is understood, makes a generalised assumption about a larger group of people who do not all adhere to the imagined stereotype, and it casts them in a negative light.
I suppose that the point you're making is that zer0gravity used the term "religious people", and that seems to be acceptable to most people, few object to it; whereas "people of color" or any other term that is deemed unacceptable to make that kind of negative assumption about, would not be okay. And that's a rather big double-standard.
Regardless though, the meaning that zer0gravity was trying to convey, was clear and understood. I think taking up offence at zer0gravity's comment and use of the term "religious people" just detracts from the topic being discussed; and I highly doubt any ground will be crossed on the point you're trying to make; at least on this page and topic.
The closing paragraph puts it perfectly. The design lends itself to production running latest trunk (because, obviously, it's assembled at runtime FROM SVN). The idea that a commit could instantly break production is horrifying.
Just another example of a developer looking for a problem to apply his solution to.
It is this moment when you search for the big red lever with sign: "EJECT!!!"
In my modest experience most companies have something like this going on. Either the guy that everybody think is a genius because he wrote a custom (shitty) framework or just the horrible process and code base.
And remember, when you interview for companies that ask you questions about the latest javascript trends, how you would design a nice one page application, how internal Go works, etc. They most likely work with spaghetti jquery everywhere and a homemade php framework as bad as in this post.
I get to work on genius code all day long.
Two WTFs for the price of one!
There's also the "second system effect", where the creator tries to avoid all of the bad things they encountered in the first system, and implement every spur-of-the-moment idea they ever had, all at once.
The first mention of JDSL is a link to an article about it: http://thedailywtf.com/articles/The_Inner-Platform_Effect
Similarly, sometimes it's useful to provide just enough primitives that a "non-programmer" can be trained on how to perform a very constrained set of operations on the data they deal with, and provide them with a simplistic language that funnels them into the types of operations they are most likely to want and away from (or disallowing) operations that are deemed problematic or complex.
The issue is that these options are usually not what you want to do. Not because they are wrong, but because they are much more likely to result in something worse, given the possible outcomes. Usually, the result is multiple of the following: too late, too slow, too complex, too inefficient, too hard to maintain, too hard to develop. That said, given a fairly lax timetable, smart people to design and develop the system with, and a clear vision of what needs to be accomplished, great things can be accomplished. But how often to do we get all that at once?
I think these kinds of things are great learning experiences, I'm just glad that abomination of mine was never released.
Sometimes this works a lot better that you might expect and the platform works pretty well, sometimes it produces Cthulhu level nightmares.
NoSQL sort of legitimized these kind of bad practices.
I've seen those sort of things all over the place in every NoSQL project I've ever worked on.
It is a relational "design pattern" used to implement a database inside a database, instead of using the database itself as it was designed to be used.
This has all sorts of fun (not) and useful (neither) effects, including: worsened performance; inability to ensure data integrity through constraints; bloated / unreadable queries; hard to find bugs; needlessly complicated migrations; and so on.
For example, Firefox extensions could be easily considered an inner platform but they have the benefit of providing a platform which is safer and more extensible than the underlying OS.
Likewise, EAV provides a poor functional replacement for an actual database. But they also prove a lower curve for implementing very simple extensions and limit the capacity for trivial mistakes. Speaking from experience, it's the WordPress sites where plugins have created a whole bunch of extra poorly-built tables that worry me most.
`wordpress_%app_table1` etc. if you want to do it ad-hoc.
PostgresSQL support namespacing out of the box[1][2].
[1] https://www.postgresql.org/docs/9.3/static/ddl-schemas.html
[2] http://jerodsanto.net/2011/07/building-multi-tenant-rails-ap...
Granted one is more dangerous than the other, but to me it's no reason to give them access. It's still a headache.
If only the developers have access to modify the structure, the way it is done is not important (it can be done through a webform that alters a database, though the addition of a json definition, through coding, etc.) After all, you can modify the schema through PHPMyAdmin. It's some kind of admin interface. You just don't grant your users the right to do it. Just as you don't grant them the right to add custom fields, unless they know what they are doing, which is seldom the case :)
I think that EAV gives a false sense of security, in that it does not "break" much if done by a non-knowledgable user. But still, if it is done badly, good luck reconciling the data.
It's certainly true that life is easier if you never implement certain kinds of features but at that rate why make a program at all?
I disagree strongly here and see this attitude a lot. It's easy to say "not my problem, you fucked it up, you fix it" but that is a very customer-hostile attitude.
Instead we should be giving users functionality they want in a way that prevents them from screwing things up through a combination of feedback and constraints. Sure, if a user types in blatantly incorrect data there's not much you can do. But you can do a lot more than say "here's a narrow ledge and a pit of snakes, if you fall in it's not my fault". This just results in unhappy customers who don't care whose fault it is, all they know is that your software ate their data.
Very in agreement here. Almost without fail, if they knew enough how to 'fix' it, they wouldn't have fucked it up in the first place.
Much of this attitude depends on org structure. Are you talking about paying end-customers? Or joe in accounting 3 doors down who consistently never follows any directions you give him re: data?
Of course, it's worth remembering that real databases do not typically use an EAV storage pattern for their data, so maybe it's not the only way to model a custom data store within a relational system.
/s
Actually, I've read about the content-addressable-function-idea before, but I can't remember where that was…
http://erlang.org/pipermail/erlang-questions/2011-May/058768...
I've worked at places that had great DSLs (both embedded and freestanding) and awful crocks that were just the right mixture of infinite funding and no accountability. The vast majority were trying to make something like database access a little nicer for their domain. Someone who doesn't want to litter their resume with the term "DSL" might even call the majority "libraries". I've certainly seen a couple that were on the level of JDSL ("Why don't we WYSIWYG build a CMS by generating XML which can expand out into PHP"), but I've also seen "writing assembler sucks! there is no C compiler for this micro! it would be way easier to write scheme ... hey look! we have a DSL for writing ECUs". In my anecdotal experience, DSLs have been the only way to stay sane in certain domains.
I've occasionally thought of using a DSL for some business logic, presumably the best way is to at least use an existing language (like Tcl) and provide business-specific verbs in it?
I don't know about you, but I have a constant backlog of features with tons of interesting problems to solve. There are places where I could build a DSL, but I am not going to because I would inevitably build something hacky and brittle that is impossible to understand and maintain (like JDSL).
I can't build new features, and increase the value of the system if my DSL is constantly breaking the system.
So don't do it. There is plenty of functionality on the .NET and Ruby platforms for me to model the concepts and objects in the domain without the need for a DSL.
I once worked for a company that used RDF for all configuration and scripting for one of its main applications.
Instead of using one of the standard methods of encoding RDF (turtle, XML, etc.) our main architect wrote his own. Specifically, he wrote an encoding based on Google Sheets. The triples were the row header, the column header, and the cell value. There were two special tables; one containing namespace aliases and one containing an index of all the tables in the spreadsheet.
To deploy, you published a Google Sheet to the web, copied the sheet key, and pasted it into a variable in the Java code's main() function (and we had a few different main classes for a few different deployment types).
Later on, he added support for encoding RDF in XLSX spreadsheets so we don't need an Internet connection to launch the app.
Let's just say that architect and I didn't get along (and he didn't get along with a good chunk of the devs either; multiple people I worked very well with quit during my time at that company largely because they couldn't get along with him).
If you want to see it, the code is open-source (some of their content is proprietary, but there's an open-source RDF store in the public repos that has the proprietary stuff removed and replaced with demo content). It forms part of the appdapter project on Assembla [0] (but only part of it; there's other random stuff in appdapter too), and there are some sample main() functions in the friendularity project on Asssembla [1] (friendularity was our repository of open-source main classes; they mostly just import stuff from other open-source projects and wrap it in a main()). Honestly, though, I didn't touch the appdapter part of the codebase when I worked there, and it's been a couple of years since I've worked there, so I don't think I can help much with running it. I think org.friendularity.bundle.demo.ccmio (or maybe org.friendularity.bundle.launcher.oglweb) is the relevant main project, but I don't remember too well, and I think some things have been refactored since we left.
[0] https://app.assembla.com/spaces/appdapter/subversion/source
[1] https://app.assembla.com/spaces/friendularity/subversion/sou...
two-column sheets.. first sheet is "default", sheet name == lang_location and overrides... column 1, except first row, is the key, column 2 is the localized value, column 3+ unused, but can provide more context information.
For example, if you are building up a queue of commands to be run in sequence with a bit of preprocessing, you might create a class that exposes: `addStep`, `preprocess`, and `run`.
At least for me, the impulse to create a DSL was always a secret desire to hide implementation details from readers so that they can see the intent of the code more clearly. Really, those implementation details are critical for maintainers to understand. Otherwise a DSL's magic is likely to hurt a maintainer when their expectations are off.
https://guidewiredevelopment.wordpress.com/2010/11/18/gosus-...
And below:
> Submit Your WTF
Stories are not supposed to be fiction. Granted, editors can't check how true what you submit is (and often, you only have one side of the story), but there seems to be so much available material out there that we don't need fictional entries.
A friend of mine once worked at a software company as recently as 2014 (it went bankrupt meanwhile) where the team of around 10 developers would work without any versioning system at all! They used folders with dates instead, and every once in a while someone would go over all the folders with the respective developer and merge the code manually.
My friend tried to introduce SVN, but the developers didn't want to invest time into learning it.
Anyway, given the stories I know first-hand, I totally believe it's a true story!
He'll seem to weave magic initially, and the company/project will launch and make money for the people involved. It's only later, when other engineers show up, that the extent of the horror becomes evident, by which point the senior engineer has already been enshrined as the "genius" behind the companies success.
Only the new, junior engineers can see the Emperors clothes for what they are.
Quibble: Anyone who comes up with and deploys that sort of system is not competent. They may be "senior", chronologically anyhow, but they are not "competent". Compenent senior engineers know about the inner-platform effect.
Similarly, to me making avoid a second reply, it's not just lack of communication that makes this system bad. The inner-platform antipattern is objectively bad, no matter how it is communicated.
The point is, this engineer, for all they're many, glaring faults, can get stuff done. Impressive stuff, even. And that's all the business dudes see in this scenario; Dave plugging away at a computer and cheques from customers showing up in the mail every month.
I suspect these "genius" programmers are damaged beyond all hope :)
From what I have witnessed myself, these guys are actually quite intelligent in an abstract almost mathematical way — that is, they are not dumb and can come across as geniuses — but their mediocre communication skills prevent colleagues from actually understanding their work, and more importantly, prevent themselves from ever realizing that what they are doing is way too experimental and (not rarely) wildly inappropriate for the task at hand.
You will hear these visionaries extol the virtues of their revolutionary framework time and time again, and that it will be the foundation of anything the company builds for years to come, but any criticism or even critical questions are dismissed with an air of 'you-just-don't-get-it-yet'. In the end either you leave for greener pastures, or the idiot savant cracks under the pressure of changing business needs that cannot be met by the big framework that only he/she (usually he) really 'gets' and quits.
Anyway, he was rarely in meetings, but a couple of folks who glommed on to him early on would extol the virtues of his 'framework'.
"You know how some people are just so smart that they can't even explain their work, cause it's so beyond everyone's ability to understand it? That's who he is, and that's what we have!" This was said to me at least once, and repeated variations of it in a couple other meetings. And it was said with pride/admiration/awe, about how awesome it was.
I countered with "if you can't understand it, and he can't explain it, he's the only one who can do anything with it, and you can't really verify if it's doing what you want/need, so how is this remotely 'good' by any metric you use for any other software in this department?"
"You just don't understand how amazing this is, and what we're able to do with it" was the response.
I distanced myself from it, but was then tasked with having to build on top of the 'web framework'. And discovered it had no support for web sessions. Or security. Or database connectivity. It was literally just mapping an incoming web request to a file, while taking a logging token from a cookie and sending it to a third server for logging activity. Given the AOP-esque nature... I had a bit of a hard time trying to figure out just where I'd actually add any sort of session management, and when I asked for someone (original author maybe?) to add this in because I couldn't figure out how to do it, but needed it, I was 'aggressive' and 'not a team player'. Ugh...
EDIT: when I read dailywtf stuff, I sometimes doubt the dramatizations, then I remember back to my days on this project, and ... have to recognize there's probably very little embellishment.
The developer that built it actually is smart, since you have to be to make something so bizarre and complex actually function at all. They are also full of ego, which gives them the need to prove to everyone how smart they are by building something very complex, whether the problem calls for it or not. What they lack is the wisdom to refrain from inappropriately trying to prove how smart they are and building something that is easy to troubleshoot and maintain.
They are able to stay where they are because management has their own egoic need to believe that they are employing and in charge of geniuses to demonstrate to their own peers how awesome they are. Instead of actually being awesome by coming up with a good business plan, executing well on it, and recognizing that your software problem is probably perfectly ordinary, and even if it isn't, you only hurt things by hiring ego-driven builders who want to build overly complex things instead of solving the problem at hand as simply as possible.
This was a fairly entertaining read: https://news.ycombinator.com/item?id=11631118
P.S: Dear Eris, please let me never turn into Tom!
Currently I try to use the following scenario as orientation: If a completely new developer would walk in and wanted to install or build or contribute to a current system/project, how much I would have to explain to this person? How many, "yes, true, but only if" style statements would I need to make?
The optimum here is, that a developer will contribute, without me needing to explain or motivate anything.
Do you use a certain approach? How would you describe it?
The system in the story is clearly insane, but every organization (not just software companies) has it's own operational awkwardness, that might look weird for new employees.
Imagine that Google has all their code in a single repository. How "insane" is that?
My point is I don't see why is it a hard requirement for a new developer to be able to commit code on day 1. Of course if you have hundreds of developers, it makes sense to optimize the process, but personally I would prefer a new college to walk me through things (apprenticeship style) rather than throw me at a repo and go-figure-it-out.
How big of an IDE and how many extensions/plugins to that IDE do I need to require? Recommend?
Can you take a fresh code clone and hit the big green play button in your IDE and go straight into debugging? How long does it take to build that first time from a fresh start? Subsequent "average" attempts?
Not that many projects add a real DSL, but I think you can end up pretty close also with just objects and language features.
And where do you then run this system? Of course in Docker container, probably picking up Linux components with apt-get from left and right.
I agree that the framework and people were definitely WTF.
However, I would at least have talked to someone before committing to the trunk, even if I thought I was just adding comments.
But seriously, this is why you have an integ/staging environment :)
And obviously, better developers.
I am Tom.
When I joined, I soon learned about "Stephen". Stephen had already left the company but he was still very much a presence. Most of his comments contained expletives, even for something simple like changing a log level: "tell Tomcat to shut the fuck up!"
Throughout the wiki, there were references to technical "discussions" around coding standards that often had statements like "Stephen doesn't like this!", which was short for "I don't want to get yelled at so we'll do what Stephen says". There were a lot of things Stephen didn't like. He didn't like Java. He didn't like private methods. He seemed on the fence about getters and setters.
But he loved Python. Boy howdy did he love Python.
Stephen loved Python so much that much of the Java codebase was uneditable. Yes, uneditable. You see, in order to write the Java code that'd be actually, you know, run in production, you didn't simply open IDEA and write Java. You wrote Python code that emitted Java. Hibernate configs, classes, the lot. Development time wasn't the fastest.
Something else Stephen hated was MySQL. He hated it a lot. Postgres was way better in his opinion. Stephen hated MySQL so much that he stripped it out of all the Puppet files one day because he didn't think the company should be running it. Nevermind that he was editing the production files for another team, so the next time Puppet ran, the predictable outcome occurred. I believe that was one of the few times his actions had any direct consequences for him.
Beyond Stephen and his hatred of all things non-Python and MySQL, the deployment process was a true thing of horrifying beauty.
You see, one didn't simply just drop a WAR file into Tomcat and restart the server process. That'd be much too simple. When you deployed, you deployed everything. And when I say everything, I mean everything.
Apache? Compiled from source and re-installed. Java? Compiled from source and re-installed. Name a dependency other than Postgres and that ish was compiled from source and re-installed. Deploying any code change was a minimum 45-minute process. Heaven help you if a bug was found.
(Oh yeah, and of course Stephen's domain user couldn't be removed from Perforce or any of the build systems because all the scripts ran as his user. Nobody knew what might happen if his user was removed. To this day the company still exists after an acquisition and I'd bet good money that Stephen's user is still out there consuming CPU cycles.)
My takeaway from this experience is that this kind of environment is pretty common, and it's because of some basic psychology in people. Engineers don't want to look stupid and their social skills are often not developed. So when you meet someone with a strong personality who uses shouting to establish technical superiority, they can get a long way.
But now he can just point people to that WTF piece and say "that's what that was". Anyone who still considers it a black mark after that isn't worth working for.
I have a 5-month stint at a huge company on my resume - one that a lot of people would really like to work for. It comes up sometimes in interviews, but I've got a good story behind it and usually come off as capable and ambitious after explaining it.
If something raises a question, ask it. Don't just assume the worst of a candidate.