Hacker News Reader

Comment by MattRogish | Hacker News Reader

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.

* Hardly ever. I haven't in > 7 years.

View on HN

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.

Because people who know the good side of java have jobs.

I generally go by the saying, baring any existing req's that abstraction patterns would help with:

'Code to use, Refactor to re-use'

Public fields for immutable objects are fine, but adding thread safety later is difficult if you use them.

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?"

Part of it is "customers want it", part of it is because people are taught "abstraction is good", rather than "abstraction can be useful".

"Object-oriented abstraction is going to change everything."

"Yeah, abstraction is good."

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.

I've worked on a couple of these systems over the years and I think it's a combination of the philosophy of those languages: http://steve-yegge.blogspot.co.uk/2006/03/execution-in-kingd...

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)...

/fizzbuzz.js/ for(var i=1;i<=100;i++)console.log(!(i%3)&&!(i%5)?'FizzBuzz':!(i%5)?'Fizz':!(i%3)?'Buzz':i);

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.

"Nobody ever got fired for buying IBM."

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.

Writing "enterprise" code is "safe".

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.

It's a blind insistence on caution.

There are thousands of things one might want to do in the future, and many managers "prepare" for each and every change they can conceive.

Sharepoint integration or it's ilk pretty much creates necessity for layers. Hide bad code behind layers is the enterprise motto.

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.

You need a certain mindset to start using a newer technology, and that mindset won't make you prone to write enterprizy code.

Or, in other words, the place that makes that kind of architecture won't allow the developers to touch anything that's not Java or .Net.

I've seen this done in a PHP project (to the extent that it is possible), so I'm pretty sure it is the mindset of the developer.

Dynamic typing is much maligned these days, but it allows you to abstract without nearly so much boilerplate.

Boilerplate is not an inherent feature of static typing - just look at Haskell or Scala.

Statically typed programs are longer because they contain more information.

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).

>dynamically typed languages leave that information hidden because it is inferrable (or irrelevant).

So do good, high-level statically typed languages, i.e. the kind with type inference. Like Scala or ML.

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.

Reply on news.ycombinator.com