
Clojure at a Bank – Moving from Java (2012) - xvirk
http://www.pitheringabout.com/?p=693
======
jim_greco
UBS has a bit of a reputation for this. Same thing happened with their US
Equities tech in the mid 2000s:

1) Bring in new blood to improve a legacy platform

2) The new blood decides to throw out everything and do a complete rewrite

3) The new system is super successful because it can focus on a much smaller
subset of problems

4) The bank runs into profitability issues and can no longer pay developers
well

5) The good developers leave en masse before everything is completely
rewritten.

6) New developers come in and spends the entire time fighting fires and
patching the system instead of building new stuff.

~~~
eternalban
6a) .. because instead of using a language designed in part to address
turnover and difficulty of keeping avant garde coders in banal and soul
sucking jobs, the management passed the business decision of "what tools do we
use?" to the said workers.

~~~
hga
On the other hand, the language chosen might ensure high turnover of the sorts
of coders you'd really like to keep, assuming you could ever attract them in
the first place.

Management has choices here, including simply making the best business will
stay good enough, or even if it doesn't, prioritizing keeping an essential
core of its technology people short of anything but completely closing down
the unit.

One thing I've noticed that's very common in the long term success or failure
of high tech companies is whether they kept their core technologists. Compare
Microsoft to Lotus and perhaps Ashton-Tate (dBase). Companies like banks may
not appear to be "high tech companies", but their "production" is done with
computer systems so....

~~~
eternalban
> On the other hand, the language chosen might ensure high turnover of the
> sorts of coders you'd really like to keep, assuming you could ever attract
> them in the first place.

I'm sure Bell Labs never had that problem :) I was reading someone's PhD
dissertation on Chill [1] and what was interesting to note was how many of the
players ended up outsourcing their software development to 3rd parties.

Software is hard.

There other day I was talking with someone in tech management from a national
chain (think malls). They are rolling their own commerce platform since
"nothing" out there can satisfy their ecommerce requirements. I didn't say
this upfront -- a potential client -- but the idea that this chain will
actually get into serious software development, develop an A team, and keep
them, is complete and utter wishful thinking.

My advice to anyone running a non-tech company is own the data and the apis
and off load the rest to a[n] actual tech company.

[1]:
[http://web.bi.no/forskning/papers.nsf/0/42215f66b6282965c125...](http://web.bi.no/forskning/papers.nsf/0/42215f66b6282965c12578df003a14ff/$FILE/2011-08-Paulsen.pdf)

------
zettke
Note this was from 2012, and the author no longer works there - I wonder how
this system developed in the intervening years?

~~~
ExpiredLink
> I wonder how this system developed in the intervening years?

It probably developed into a great opportunity for consultants.

------
tormeh
I always thought critical applications like banking needed compile time type
checking. Clojure is neat and all, but it's dynamic.

~~~
BjoernKW
Most of the times, they don't. Static typing helps with catching certain types
of errors long before the compiled code arrives in production but it's just
one tiny factor that contributes to overall software quality. Lack of
expressiveness or lack of developer happiness can be much more detrimental to
software quality than lack of static typing.

~~~
xfalcox
I second this. I'm currently creating a new dynamic website, which will see
around 10k users a day.

We could have done it in a week with rails scaffolding capabilities and the
vast gem environment, but we are doing everything manually in Scala, because
type safety and performance. It's so frustrating that I'm looking forward to
quit very soon.

~~~
mercurial
This is a weird complaint.

The fact that Rails has scaffolding and whatever Scala framework your team
uses doesn't has little to do with type safety (there are plenty of web
frameworks in dynamic languages without scaffolding as well).

There are several languages which require a comparable amount of typing to a
dynamic program, while adding considerable type safety.

------
lmm
One of the reasons I went with Scala instead of Clojure is that you don't
"just have to make a jump". You can write one class, in code that clearly
corresponds 1:1 to what you'd write in Java, and the interop is smooth enough
that other classes don't notice that this class is in Scala. Later on you
(hopefully) are writing a very different style of code, more declarative and
immutable and putting much more of the business logic into the type system.
But it doesn't have to be a big-bang switchover; you can be productive from
day 1, hour 1 even.

~~~
htor
I think you missed the overall point of the author, which was that in order
make a significant improvement at all, you need to make a radical shift in the
modelling of the system. One of the problems mentioned was the inherent
complexity of using a type system for modelling data. Scala is very type
oriented and so as a result you will end up with a lot of types for everything
there as well.

Yes it's certainly easier to make a transition into Scala, but I don't think
using Scala will solve the actual problem, even if it does have FP
capabilities and encourage immutability.

~~~
AnimalMuppet
As I read the article, though, it's not just types. The fundamental problem
was that nobody there had a good idea how to architect a Java application that
large. So they threw out the Java, and replaced it with Clojure, which they
had even _less_ experience architecting. Sure, Clojure may have resulted in
100,000 lines instead of a million, but that's still a large enough system
that architecture matters. Did they create another large mess? It seems
reasonably likely that they did.

Java's types aren't broken enough to _force_ you into a terrible architecture.
Trying to use them badly (that is, in the way that everybody seems to think
that you're supposed to use them for enterprise apps) seems to be the actual
culprit.

------
arh68
See also: Clojure at a _Newspaper_! [1] This guy should write a Clojure: War
Stories book.

[1]
[http://www.pitheringabout.com/?p=1018](http://www.pitheringabout.com/?p=1018)

------
mattmcknight
This article conflates OO and strong typing a little too much. These are too
very different things, but agree that the combination can cause problems, not
to mention that so many Java architectures are pathological in terms of
struggling to find the code that actually does something.

------
postit
Brazilian Startup Nubank
([https://www.crunchbase.com/organization/nubank](https://www.crunchbase.com/organization/nubank))
is also clojure based. They use datomic, spark ...

------
moomin
These days, Jon is one of the main guys at Juxt.Pro, a London-based Clojure
consultancy. They're very good... :)

------
spiralpolitik
It would be great to see examples of the design/modeling of the system. I
really like functional languages have done since my university days, but there
seems to be a dearth of examples on how to actually lay such large projects
out in Clojure/Scala etc.

Having something like the J2EE Petstore (for all its sins) would go a long way
to allowing more projects to make the switch than more articles on how great
things are.

------
ABS
Here's the video from his talk at EuroClojure 2012

[https://vimeo.com/45130708](https://vimeo.com/45130708)

------
d4n3
I love this quote in the comments:

> when you have REPL you are TDD’ing in a different way as opposed to
> constructing persistent unit-test classes that could potentially form a
> layer of cement.

Lately I've been using the console for development in rails and javascript
more than anything and it is a really good way to iterate on a solution
quickly.

~~~
mercurial
It's great for quick feedback. It's less good when your coworker breaks the
build on a less-used codepath because there are no unit tests to run.

