Sometimes I think the industry's obsession with "code reuse" is what enables these architecture astronauts in the first place. If people accepted that most code is ephemeral and never going to be reused, then architecture astronauts have much less idealogical cover for their disastrous schemes.
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.
Right? I mean, special snowflake libraries that everyone can use do exist, don't get me wrong, but they're usually created by people whose sole job it was to create exactly that, a reusable API for <insert domain here>. There's very rarely an opportunity to repurpose old code in a new project if the goal of "API-izing" it wasn't in mind when it was written, and many times when people try it's a disaster.
If code could be re-used efficiently, we wouldn't need half as many programmers as we actually legitimately do.
The primary problems in that article are nothing to do with technology.
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.
Process is the preventative of 'bikeshedding'. It's not so much about security as consistency, and it also prevents having the "why are we doing it this way" discussion every single time.
I read TDWTF as cautionary tales. I find this one to be reasonably (and scarily) believable. This 'Tom' guy probably looked at Subversion and decided, 'hey, history tracking is a GREAT thing, but I want to be able to see the history IN THE FILE ITSELF.' Thus was born JDSL.
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.
Even if I have never had this sort of Content Addressable Function "solution" I can still relate very much to this story. A story consisting of $NEW_PERSON entering some huge existing project, with $NULL_AMOUNT of documentation, where there is some established "hegemony" of some inaccessible $GENIUS, with $ZERO_AMOUNT of help and support, where bosses will likely to $YELL or otherwise treat you as a problem, where every move is very fragile and often leads to $CONFLICT... I surprises me how archetypical is this.
It is this moment when you search for the big red lever with sign: "EJECT!!!"
This is literally what I'm doing atm, on my first non-basic-bigfixing issue at a new company. Something that should have take two days has taken three, going on four weeks, I feel like a shitbag fraud for not polishing it off in two days (due to.pain time refactoring and seperating concerns). Noone can give me advice because <particular deity> left the company, and anyway they're rebuilding everything in <internal JS framework with no external deps>, but this critical feature needs to be done in place. Been in this situation before as well, thought I'd managed to escape...
This is hilarious but I don't take this as a satire.
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.
You can tell they're a genius when only a genius could have concocted something so complicated and convoluted and still make it work. I seriously don't doubt that Tom had an off the chart IQ, but intelligence doesn't automatically lead to sensibleness.
See, I think the real mark of a genius is being able to make connections and see possibilities that are harder for normal people, and make something obvious and simple. You don't have to be a genius to code yourself into a corner. We've all done that before. Most of us weren't so full of ourselves that we couldn't eventually recognize our mistake though.
I have a theory that every programmer, at an early stage in their career, comes up with something approximating the 'metadatabase'. The only difference between any of us is how quickly we realise it's an appalling idea. There's a grey area: I've worked with databases on internal systems with key/value tables that just about make sense and were small enough to be manageable. It's when you see this kind of crap in production, third-party products that you want to run a mile.
This is a common everyday story with NoSQL databases these days. One document/table format with 100's of fields like col1, col2, col3... so that they can stuff in whatever they want without having to think through schema design. If you try to confront it, they label you as outdated programmer from the 90's.
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.
This is stupid. Why would they write JDSL if they could just have used https://github.com/josh/cafe-js which is clearly superior because it uses Git instead of SVN?
Typical case of NIH.
/s
Actually, I've read about the content-addressable-function-idea before, but I can't remember where that was…
Run for the hills any time anyone says, "It's our in-house developed DSL!". It's a virtual guarantee that whatever was cooked up is some sort of insanity like JDSL.
I saw similar levels of ridiculousness with XML during my (brief) time working with Enterprise Java many years ago, although it didn't go as far as the use of Subversion... but I did experience a lot of the "you just don't understand how beautiful it is" sentiment from the architecture-astronaut creator(s) of these behemoths. Now that JSON is the "new modern XML", I'm not surprised at all that things like this have come into existence.
> Founded in 2004 by Alex Papadimoulis, The Daily WTF is your how-not-to guide for developing software. We recount tales of disastrous development, from project management gone spectacularly bad to inexplicable coding choices.
Remy Porter is the editor-in-chief and needs to read your story or see your bad code.
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!
It's usually a combination of a competent but misguided senior engineer and a fleet of buisiness dudes who aren't qualified to assess whether the engineers work is actually any good.
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.
The kind of people that come up with this stuff usually are in fact really good at visualising an abstract problem and implementing it in code. What they often lack is the capacity to translate what it is their frameworks do to language others can understand.
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.
When you don't understand something it's impossible to tell whether the creator was a genius or an imbecile. This is probably why hiring a sole programmer in a start-up is such a nightmare. And I speak as one who is that sole programmer.
It fulfills complementary anti-patterns both with the developer and the management.
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 story could be fiction, but I don't think so. For starters, it takes some serious imagination to come up with a system so broken. And I have seen a system, written in a javascript dialect, execute by an in-house javascript engine written in Delphi, that you had to use the in-house IDE because it was the only way one could find the desired functions. You see, the 'module' system worked by referencing database IDs, from a database table that contained the javascript "file" you wanted to import...
JDSL sounds like a capital idea, but obviously Subversion is much too slow, and Javascript/JSON is not enterprise-compatible. Someone should re-implement it using EJB's, XML and an Oracle backend to store the functions in.
P.S: Dear Eris, please let me never turn into Tom!
So many things can go wrong. But how do you assess, where to draw a line? What could be used as a guiding light?
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?
Is this really that much different from any other industry though?
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.
If a competent senior developer can't come in and make a commit (even a simple one) on their first day, your system is too complicated and should be rethought.
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?
This story is like a parable that condenses all my work experiences so far. The problem is that management is easily terrified and impressed by anyone who can flummox them with tech buzzwords and knows just enough programming to be dangerous. They get in early, create a horrific mess that takes other people at least a year to untangle enough to be able to maintain. The company talks forever about rewriting it - but everyone's too busy putting out fires in the spaghetti to work on the newer better architecture. Really, most of the crap these 'geniuses' write could be quickly replaced with something off the open source shelf. But the customers are too entrenched in the proprietary spaghetti, so they can't, etc. And every new 6 figure tech guy they hire just tries to create his own cozy nest of over complex code in a sad attempt to create job security. Its all a scam.
Think about all those dependency management systems (npm, Maven, NuGet). Look at a project with huge number of dependencies, picking on piece of functionality from one library, something else from another. All tied together with some depedencies file and maybe with some additional dependency injection magic. Not backed up by version control, but instead the package repository.
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.
[+] [-] overgard|9 years ago|reply
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.
[+] [-] nameless912|9 years ago|reply
If code could be re-used efficiently, we wouldn't need half as many programmers as we actually legitimately do.
[+] [-] dexwiz|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] anonymousguy|9 years ago|reply
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.
[+] [-] pjc50|9 years ago|reply
[+] [-] zer0gravity|9 years ago|reply
[+] [-] gargravarr|9 years ago|reply
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.
[+] [-] haddr|9 years ago|reply
It is this moment when you search for the big red lever with sign: "EJECT!!!"
[+] [-] RobertKerans|9 years ago|reply
[+] [-] grosbisou|9 years ago|reply
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.
[+] [-] mark-r|9 years ago|reply
I get to work on genius code all day long.
[+] [-] kbenson|9 years ago|reply
[+] [-] donatj|9 years ago|reply
[+] [-] _pmf_|9 years ago|reply
[+] [-] shangxiao|9 years ago|reply
[+] [-] oneeyedpigeon|9 years ago|reply
[+] [-] pdpi|9 years ago|reply
[+] [-] kamaal|9 years ago|reply
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.
[+] [-] zeveb|9 years ago|reply
[+] [-] martimoose|9 years ago|reply
[+] [-] svckr|9 years ago|reply
/s
Actually, I've read about the content-addressable-function-idea before, but I can't remember where that was…
[+] [-] WDCDev|9 years ago|reply
[+] [-] userbinator|9 years ago|reply
[+] [-] rollulus|9 years ago|reply
[+] [-] clifanatic|9 years ago|reply
[+] [-] EnderMB|9 years ago|reply
http://thedailywtf.com/articles/We-Use-BobX
[+] [-] scrame|9 years ago|reply
[+] [-] petetnt|9 years ago|reply
[+] [-] junke|9 years ago|reply
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.
[+] [-] Jean-Philipe|9 years ago|reply
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!
[+] [-] ahoka|9 years ago|reply
[+] [-] s_kilk|9 years ago|reply
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.
[+] [-] Freak_NL|9 years ago|reply
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.
[+] [-] oneeyedpigeon|9 years ago|reply
[+] [-] ufmace|9 years ago|reply
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.
[+] [-] cstuder|9 years ago|reply
[+] [-] Confusion|9 years ago|reply
[+] [-] ckastner|9 years ago|reply
This was a fairly entertaining read: https://news.ycombinator.com/item?id=11631118
[+] [-] outworlder|9 years ago|reply
[+] [-] Kristine1975|9 years ago|reply
P.S: Dear Eris, please let me never turn into Tom!
[+] [-] maze-le|9 years ago|reply
[+] [-] firephreek|9 years ago|reply
[+] [-] mtrn|9 years ago|reply
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?
[+] [-] sly010|9 years ago|reply
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.
[+] [-] morgante|9 years ago|reply
[+] [-] WorldMaker|9 years ago|reply
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?
[+] [-] diyseguy|9 years ago|reply
[+] [-] jpalomaki|9 years ago|reply
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.
[+] [-] new_hackers|9 years ago|reply
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.