This seems to be implemented in a single programming language without any dependencies on legacy systems. A truly enterprise-grade system talks to PL/SQL stored procedures. Or it would, if the DBAs had written the stored procedures. But they haven't responded to your ticket request yet. And when they do, it will be with a mostly irrelevant question delaying actual work for another week. by which time their manager will be offsite at OracleWorld and won't be able to approve the changes.
Also it would be nice to configure the strategies with XML. Plus it would be super helpful to have jar plugins for new strategies. And seriously, there's no SOAP interface? This is hardly usable then. Also how the heck am I supposed to build this without Ant and batch and shell scripts to call Ant? Plus once you get ant files you can integrate it with Hudson. And package this as an EAR and add some user authentication too, probably single sign on. Also needs some log4j. And there are probably all sorts of unforeseen bugs and style issues, so it needs Findbugs and Checkstyle integrated.
You're right. There are so many issues with this, on top of the ones mentioned.
No serious enterprise-grade software today would do without leveraging Maven, annotations, IoC, AOP...
And why isn't the UI decoupled from the business logic? What happens if one day another team in the organization needs access to Fizz Buzz? Writing their own Fizz Buzz would be extremely redundant (even dangerous), and if anybody changed the logic of Fizz Buzz it would have to be changed in multiple places at the same time: a simple change like making "Fizz" print every fourth time instead of every third time would make every Fizz Buzz team go through architecture, various change management meetings and at least one weekend deployment. And all of this would have to be coordinated to make sure it all happens within a single change window (assuming this could even be rolled out in a "big bang" situation).
No problem. IT solves this problem easily with the seamless integration of EJBs, or SOA (as mentioned), or a modern plug and play ESB. There are multiple ESB vendors, each with their own advantages and disadvantages, so best practice advises organizations to create a working group comprised of all the stakeholders of the organization with the aim of reaching a consensus on the best product to use and the best way to move forward with this (it's more than likely the whole company will want to move to an ESB platform quickly because everybody likes to leverage and everybody likes things that are seamless). The team does not have to be very technical (the brochures and online PDFs explain things very well). Plus anybody inside the organization who thinks they need to participate should be involved.
On another note, the programmer who decided to take the initiative and write this needs to have a one-on-one with his or her manager immediately. Even organizations that value proactivity will find problems with this: there is a strict violation of at least one of the basic principles of enterprise software. I don't see any constants defined and everybody knows that "the enterprisocity of an application is directly proportionate to the number of constants defined."
Thank you, yes, I forgot so many things. And most important, where is the test suite for this? I'd expect at least 80% line coverage and would like to see a coverage report to dive down into the specifics. Additionally, it would be nice to have some performance numbers as a base line for sizing, and timing of each method.
Further, what's the license on this? I'm afraid even if it's LGPL I can't go near this.
There should also be other applications that do almost exactly the same thing but display the information in a slightly way but use a completly different code bases.
* provision one ec2 instance per number to check
* assign numeric order based on uptime in msec using zookeeper
* serve result via json
* render it on the client.
I've often wondered - is it the language that spawns this or the mindset of the developer (or both?)
I see this primarily in Java or .NET shops - massive layer upon layer, code generation, factories, classes, etc. - when a simple architecture would be best. Why do we get these insane things to begin with? What's going on?
It feels sort of like premature scaling (what if we have millions of programmers - we need more abstractions!) combined with misuse/misapplication of design patterns.
You'll never* see stuff like this in Ruby on Rails, JavaScript, Python projects, etc. I'm curious how one goes from a simple, elegant program to over-engineered monstrosities.
It's environmental, largely driven by a) the need for cost certainty, and thus the susceptibility of non-technical management to the allure of the Bag Of Magic Beans sales pattern (see also: the fungibility of skilled work fallacy); and b) the need for risk abatement in large organizations.
I've always found it most useful to think of this sort of garbage as an effort to hedge against terrible communication. Sure, it's likely to be a load of blood sweat and tears spent on useless tangential silliness; but one time in a hundred, the plastering of abstraction over ill-definied abstraction will allow a team to anticipate one step ahead in the chain of ever-shifting requirements, and thus, earn back a few hours and a tiny shred of dignity.
Nobody really likes this crap. But the life of the mean programmer is a grim one, indeed. Ultimately, the problem is that nobody really knows how to write software.
I wonder too. I write a very atypical brand of Java (I like to think of it as "unencumbered Java"). I sometimes even use public fields instead of accessors (o, the heresy).
My best guess would be that you often need to refactor you code to include some of the patterns showcased in the repo (factories, for instance). So developers try to future-proof their project by using those patterns everywhere. This is obviously a terrible idea.
Now for the bitchy part, why does no one ever speaks about the good sides of Java?
So developers try to future-proof their project by using those patterns everywhere.
Something I've seen a lot (and been guilty of myself) is trying to fix the problems of past projects in new projects before they crop up.
A better solution is to not be afraid of refactoring (tests help here) so you can solve the problems when they become a problem, not create complication before.
> Now for the bitchy part, why does no one ever speaks about the good sides of Java?
Cause at some point most of them got tired to preach about Java and continue to do great work vs worrying what other people think.
Look around: NetFlix, Yammer, Twitter, Google are all using Java to power either their infrastructure or apps. Nobody blogs about it because "It Works" ;)
The rest blogs how they keep jumping between wagons :P
this joke thing isn't really about Java as a language though. its about a very weird/bad and surprisingly common design anti-pattern. Java was used to do this joke because its utterly typical for this type of work, but certainly you can have this kind of disgusting enterprisey garbage in just about any programming language.
nobody makes jokes at the expense of well written Java software because its well written. we all know that the language is perfectly fine, and in alot of ways quite good, when it is used by sensible engineers.
Must be the mindset. I've seen plenty of straightforward, well written C# code with none of this garbage. I'm sure it's the same with Java. And you would see plenty of Ruby code written in this kind of style if Ruby was popular in enterprise software development.
I agree with that. For example, Azure storage is pretty straightforward and simple to use [1]. Or LINQ, which is part of the .NET framework and is beautifully simple to use.
Part of it is "customers want it", part of it is because people are taught "abstraction is good", rather than "abstraction can be useful".
So folks abstract everything, because they don't stop to think about whether it makes sense.
You know, just in case the day comes when they need to send requests using carrier pigeons instead of TCP. They never stop to think whether "in a world where we need carrier pigeons, would this app be useful anyway?"
Have to agree there... but without having to support/supplant multiple systems simultaneously, or in support of rigid testing, it doesn't make much sense.
In the former case, it's usually easier to rewrite than write a new, compatible abstraction... in the latter, with simpler more custom interfaces, testing can be smoother than a lot of frameworks for these things.
Not to defend the indefensible, but why not make a couple of discussion points...
If you have a huge application and a high staff turnover you want to minimise the amount of information in your developers' heads. Strictly architected code can do this to some extent, and can go some way to reducing need for that other 'enterprise bane' - documentation. This is less of a problem in a startup type environment were you can find out about a particular piece of code by walking over to the kid that wrote it and having a chat.
Code generation (mentioned elsewhere on the thread) is another example of something that is less necessary in a small environment. Matching an enum to the contents of a database table or whatever can be done by convention to begin with, but it's less practical if your development team is spread across three timezones. Better to invest the time in letting computers do the work.
And partly a correlation between the type of company that chooses a "proper", statically typed, "enterprise ready" language and the type of company that hires "safe pair of hands" programmers who value predictability over getting stuff done.
Honestly, I'm not sure where it comes from... I tend to bypass/rip out this kind of obfuscated crap from projects wherever possible... "Microsoft Enterprise Library" is about the bane of my existence... I've only seen two projects in the 11 or so years of .Net development where it was a good use case.
Lately, for smaller one-offs, utility scripts etc.. NodeJS is my tool of choice. Even where it isn't the fastest choice, it tends to be one of the easier choices without going to a language the rest of the systems don't use (JS is used on the web, so web devs need to know it anyway)...
I almost feel like, as a programmer, you can get "calibrated" to a certain level of architecture or designed-in flexibility, and then any time you have to code something "lesser", you end up adding architecture and boilerplate until it looks like the things you're familiar with.
Look at the HTML5 IndexedDB API, for example: obviously designed by someone "calibrated" to coding web browsers, not someone calibrated to doing web scripting.
It all comes down to testability. In statically typed languages like C# and Java, it's very hard to test a class in isolation without abstracting hard links between classes, segregating interfaces, inverting dependencies and so on.
You can write "simple" systems in those languages that have the code purity you're looking for, but they won't be very testable.
In the dynamic languages you mentioned, you have duck typing and testing is a walk in the park.
If you are new to an organization, do you rock the boat and fight for code-reviews for nice looking code, or do you bite your tongue and and write enterprise code to make everything go smoothly, from an administrative standpoint? You are not going to be scolded and forced to defend yourself for the enterprisey code, even if it ultimately was the wrong choice.
From what I see it is usually well intentioned but not exceptional developers trying to write "good code".
They know some sort of abstraction is called for, but they end up picking abstractions which are actually a net negative for code complexity, rather than a positive. If you have enough of these developers then it devolves into code very much like the OP.
There is also a resistance to large refactorings which "clean house" of these sort of abstraction errors in enterprise teams and a lack of developers with the skill (and balls) to do it. So this cruft tends to accumulate.
Then angularJS dropped. Now we see it there as well.
[disclaimer: I am programming a service in angularJS for the client and SpringMVC for the server. My code looks exactly like this. I cry myself to sleep every night.]
I agree with you. It seems like Java programmers at enterprise ignore Cohesion vs Coupling tradeoffs. Every class and abstraction they write is so tightly coupled which causes issues when debugging or just trying to figure out how to add a feature enhancement without writing more classes. Working as a software engineer, it sucks looking at a 1000 lines of code to do something simple that can be done in 10 lines elsewhere --> means that OO is not the right way to go about things sometimes.
they don't contain more information. they contain more explicit declarations of that information. dynamically typed languages leave that information hidden because it is inferrable (or irrelevant).
indeed. Scala's type inference system is truly beautiful. lets hope it catches on and becomes a widely adopted feature of the next generation of languages.
If you want to see a really beautiful type inference, take a look at Hindley-Milner. Not only is it global (it infers all the types in your program) but it's also surprisinlyg simple--it's basically just a straightforward constraint satisfaction problem.
In particular, take a look at how it has been extended by real languages, especially OCaml. OCaml has some very cool sub-typing features but manages to maintain global inference, unlike Scala. (Largely by choosing structural rather than nominative sub-typing.)
So some languages have had better type inference for longer than Scala has been around.
When the programmer is the one that has to be doing the inference you refer to, there seems to be a good argument that the speed advantage you refer to is only apparent in programs small enough to conceptualize in their entirety.
Amateur hour. Serious Business this is not. Where are the tests? The Inversion of Control? The logging? The analytics system? Documentation? Architecture diagrams? Someone should either fire or promote this engineer immediately.
And he should have used a CHAIN OF RESPONSABILITY pattern instead of the IF/ELSE to handle each case , and the FOR loop should have been handled by a STATE PATTERN , finally the system.prints require a full BUILDER to decouple datas from rendering triggered by COMMANDS , that work is indeed "amateurish" , especially without a SERVICE LOCATOR.
"One-liners lead to unclear code that has too much responsibility crammed into too little space. It's better to do less per line and keep the code readable. This changes the very complex and ambiguous operation <= into two separate, easily understood operations < and ==."
Last week my colleagues and I realized that the official, Zend-provided, XML-based communication system that allows our PHP middle-end to talk to our RPG-based backend doesn't allow you to return any character string that includes a less-than symbol.
One of our routines returns a SQL string.
Sometimes SQL strings contain less-than symbols.
After much handwringing and an official bugfix that fixed nothing whatsoever, we decided on the next-best solution: all instances of `where foo < bar` must be generated as `where foo != bar and foo !> bar`. I shit you not, that is a not-greater-than operator.
I may sound frustrated, but I'm not. We all had a good laugh at the workaround and got back to work. This sort of thing is sometimes known as "job security".
Ha! You think any enterprise IT shop is going to trust an open-source product like Subversion with their mission-critical source code? It would be in Perforce or MS Team Foundation Server.
Sometimes they don't have a say. I've worked with several large fortune 500 companies who use SVN, regardless of how much the IT Department objected to it.
Eh, Perforce is too pleasant if we are really embracing enterprise; makes it too easy to do sensible things like use a git client. No, it has got to be SVN for maximum pain.
Besides the "modern" VCS's, I've used SVN, CVS, Perforce, and done both manual patch management and patch management with Quilt. I am sure there are some VCSes out there I would hate more than SVN if I used them, SourceSafe I'm sure, but I would honestly use any of those others I just listed before SVN again. Yes, I consider SVN to be a devolution of CVS.
Can someone tell me why Java seems so to have developed into this kind of chaos? It isn't just enterprise java, has anyone looked at the Apache java projects lately?
Tens of thousands of lines of dependency xml (that often doesn't even work because of incompatible common dependencies), three different built systems (ivy, ant and maven), abstraction for classes that have just a single concrete version, dependencies that are old and no longer supported (I'm looking at you Apache Gora). Hell, find the download link on most Apache java project sites. Now find the one for the source repository.
What madness has infected Java developers?
(Sadly, I've recently had to start doing a bunch of big data work with hadoop, possibly the most fractured and poorly documented open source project ever created)
It is not as common these days, but the "enterprise bug" pops up with C++ sometimes as well. "Enterprise C++" doesn't look quite the same as "Enterprise Java" (generally the build tools/system/etc are not particularly enterprisified), but when you see it you'll recognize it as the product of a similar mind by it's distinct smell.
Where is the Spring dependency injection stuff? You can't just hard code all your Factories in FizzBuzz.java, you need to specify everything using XML so you can switch Factories without going through a recompilation.
Exactly. No Spring, no Maven...I mean, come on. Plus, I'd like to see some Camel routing defined for sending my crucial FizzBuzz results to various endpoints.
Oh yeah, and what about when I want to run scheduled FizzBuzz? Obviously I need Quartz, which requires...more XML!
Let's not get into the necessity of making a FizzBuzz OSGi bundle - we'll tackle that in the next iteration.
This is terrifying. It's like a docu-horror flick for programmers. I actually felt depressed, anxious, frightened, and dispaired going through that code.
I think a lot of programmers in the enterprise world are consultants and paid by the hour or day. That means longer it takes to solve a problem and then later support it the better. You are paid more for working on the project longer. That naturally drives people to create elaborate schemes for simple problems and make more money.
I give another example where goals and rewards are misplaced.
India has a serious Cow problem. Every city in india has thousands of cows roaming freely on the streets. New Delhi, india's capital decided to solve this problem by hiring workers who would take this cows from the streets , put them in trucks and move out of the city. They get paid for the number of cows they collect every day.
Guess what happens ? They release the cows next day into the city so that they can collect again and make money.
Anywhere there are goals and rewards misplaced, inefficiencies will creep up.
This is how I learned Java in software engineering. Simplistic if/else logic transitioned to enterprise madness. It left a bad taste for most of us in the program.
If you are a teacher in this position, provide fleshed out source/examples of enterprise software/requirements and have the students extend the functionality. Using minimized examples to prove the concept leads to rebellion/disgust.
I haven't actually seen java in package names, but I can easily imagine the conversation where some over-planning architecture astronaut decides that the project may need code in another language in the future (without bothering to worry about if that language even uses Java style packages) and so they better make a directory that is specific for the Java code so they can keep the other code separate, if they need to add more languages in the future.
I've not seen it directly in the package names, but I've definitely seen project hierarchies with source/java even though no other languages were used (or going to be used, for that matter).
never having been in such a situation, I wouldn't know, but this is the first time i'm hearing of people putting java within the package name (for something that's not part of the java namespace)
What if you did a Poe's Law version of this? That is, try to create the most contrived parody of a solution to FizzBuzz possible, but one which still fools at least 50% of interviewers into thinking it's a legitimate response.
I'd love to see a branch of this with your suggestion, though... and maybe a script that would automatically generate a file structure that reflect the namespace of serious business with which one is interviewing. You know, for fun ;)
Haha, i remember this new java guy at my (games)company that implemented his version of a skill/weapon system and in the end had like 20 Different Classes/Interfaces/Abstract Classes/Factories. It worked, but was horribly over engineered and much harder to understand than a much simpler version we made out of it.
Abstraction makes code harder to read, so use it wisely!
If you want to turn this into a SaaS solution, I would be happy to donate the domain FizzBuzzAPI.com to your cause. I think the community would really benefit from being able to offload the overhead of solving FizzBuzz problems to an external service.
print(type("",(),{"__call__":
lambda self, start, end:
[(n, (lambda x: ("fizz" if x % 3 == 0 else "") + ("buzz" if x % 5 == 0 else ""))(n))
for n in range(start,end+1)]
})()(1,50))
I can't tell if some of the obviously missing patterns are accidental or just representative of that usual type of code with all of the wrong patterns and none of the right ones.
unironically exist in a language "aimed at bringing "fun" back to programming. By providing a small and easy to learn programming language in a friendly and inviting development environment, Small Basic makes programming a breeze"
Accepting pull requests! I've had a couple mind-blowing contributions in obscure languages, my favorite being a provably correct Fizzbuzz service written in Coq:
That's great, but we're here to make fun of "Enterprise" programming and anything associated with it. Now you come along and give us this simple example that works.
I bet it would still be better in Javascript or Ruby because those are the only two languages that I know and everything is better as a web app anyway.
Want to see this kind of stuff done entirely seriously? Search for solutions to the "Thoughtworks rover" problem. When you see a class for each direction you might be heading, you know you're on the right track.
I met some c# guy who did the whole enterprise thing in his version, but it wasn't tongue in cheek at all.
in my head I went, this is why the whole ms enterprise stack sucks balls. the sad part is that they actually think it's good to abstract away something really simple.
EDIT: removed the link, sorry for offending you dude
Your comment offends me, but on a light note, for every 1 developer doing the enterprise overengineering crap, there is a dozen of us C# guys who are doing the opposite where I work.
No, C# best practices look nothing like this. I have no idea what happens in Sharepoint land or deep in the enterprise and MS Office stacks, but the core of .Net is not over-engineered to this level. Factories, FactoryFactories, and XML-configurable dependency interjection frameworks are nowhere to be seen.
No. I honestly want to see some of this great code that I keep hearing about.
It's just hilarious to me when people think their shit doesn't stink and so I rub their faces in it.
Have you seen the code for Node.js? It's fucking disgusting. Yet everybody around here can't get enough of it. Seriously...I'd love to see how some of these developers would deal with enterprise requirements. I think the problem is that they just don't understand that business is chaos, it's not like building some pie-in-the-sky single-purpose social media application.
It's quite common in these parts to be honest to piss on .net/Java 'enterprise' code.
Many of the folks here haven't seen what kind of systems banks and other big companies work with, so they have this little start-uppy world view with tests and orm's and the like, where vulnerabilities in their software are touted as 'the price to pay for being agile', so it is very hard for them to understand some of the practises in big companies. Now sure, I've seen some bad code in there as well, but I also seen a lot of bad code in Rails projects (heck, before the idea of fat model skinny controller, most of rails programmers had controllers the size of the moon, then cam fm-sc and now models are enormous, but in rails 4 we will have concerns which I'm sure will result in same clusterfuck, and the interesting thing is, before fm-sc, rails folks said 'yeah, controllers are supposed to be like that', then with fm-sc 'no no, it's like this now', and now we get to concerns and will be the hot topic, and they keep rewriting and rewriting and touting how .net/java devs don't know what they are doing, while these devs have code in production and still in development for decades (well, java at least) in systems they can't even imagine the complexity.
tl,dr: stop assuming .net/java devs are shit and you are the best for using rails or python, chances are, you suck as much as them.
In all fairness, banks in general have shit security and willfully ignore good security practices. I can configure my Facebook account to have better security than most banks.
"in my head I went, this is why the whole ms enterprise stack sucks balls."
Brilliant. So, if some random programmer built some way-over-complicated Javascript solution, would you think that the entire web platform "sucks balls"?
"the sad part is that they actually think it's good to abstract away something really simple."
Who is they? Microsoft, this random c# guy or all c# programmers? If you answer anything but "random c# guy", I'd like your evidence please.
Also, let's see some of your code please. Not fizzbuzz. I wanna see some of your real life code.
The problem isn't random programmers, it is a culture and tool ecosystem which says that this is the right way to do things. If it were just one random programmer, there would be nothing to complain about.
If some guy decides to write his website in his own dialect of Visual Basic, that isn't really being inflicted on anyone but his employees. The deeply-nested StrategyFactory stuff is an infection which worst affects languages like Java and C# (recruiters call it "OOP") because those communities do not strongly reject it.
Why do JAVA, C# (and the like) IDE's have such complex feature sets? Is it not a reflection of the complexity that those ecosystems require for maintaining your code?
Which feature set? The core of these IDEs is a debugger that is highly integrated with a text editor. Is there a problem with that? IDEs often show me the files that are in the project. Another common (core) feature is code completion. Also, integration with common source control systems. Too complex yet?
You didn't mention XCode. Why not? It has all of those features. So, it must be the non-core feature of IDEs that makes one seem complex and the other not. Which features are you talking about?
I concede you make a good point. Most of the features you listed I end up using via command line rather than it being integrated directly in my editor. Maybe part of what i see as complexity is just my cheese being moved. However, and correct me if im wrong, IDE's are more popular with "powerhouse" OOP languages in general. I always thought that it was because navigating these types of projects with just a simple text editor was too cumbersome without the editor being aware of context.
so overcomplicated javascript is not overcomplicated?
i just started working on microsoft enterprise garbage. ever had to deal with sharepoint, dynamics?
even microsoft developers say you're doomed when you're being put on a sharepoint project.
I just codereviewed code for 2 different dynamics contractors. Both highly recommended by microsoft. both of them had high levels of abstractions, but the end result was tightly coupled anyway.
Their javascript was written the same way. The real joke of it was that I had never done anything of the likes.
Want some of my real code from many years ago? go through mplayer/ffmpeg
Say what you want about the culture but I've found MS's stack to be quite good with the right team. It's got some great features. LINQ in particular springs to mind.
There are plenty of terrific systems built atop that stock. StackOverflow is implemented in ASP.NET, for instance.
dude! microsoft is not just enterprise. they have the biggest r&d lab with some really awesome shit going on.
linq is made by the haskell guy. well the haskell guy was a microsoft guy. but you get the idea. it did not grow inside of the .net enterprise culture. it grew outside of it. I never had any qualms about c# as a language. but that's also not what we're discussing.
just like f# is wonderful. but it too did not grow inside, but outside. they're being really smart about tying it into the enterprise as much as possible therefore guaranteeing it's future though.
Can you get this into a Maven repo? I'd like to include it via my pom.xml, I have some numbers that need FizzBuzzing and they always say great developers never repeat the work of others.
God... this is particularly painful because I remember first seeing this in a thread on boards.4chan.org/g/... and now, several months later, here it is on hacker news.
