Clojure at a Bank – Support

October 24, 2012 § 2 Comments

My last post covered the rationale behind our team at an investment bank wanting to make a switch to Clojure from Java. I want to write in this post about how we were supported in our efforts by those at the bank.

Aircover from Within

First not all the team jumped in at once to use Clojure. We created what we called a ‘pod’ within our team. Invitation to the pod was extended to all but to join you had to get the Emacs/Swank/Lein environment setup working first by reading our projects github README page. People joined the pod at varying times with their own personal approach. I.e. some devs wanted some space to try out their own thing in the Clojure codebase whilst others wanted to pair up. Some devs wanted to install the very latest version of Emacs themselves and understand all of our Emacs config whilst others took a more direct route through to the code. At one point we had an Emacs versioning arms race of which I dropped out.

Some of the team didn’t join the pod initially and stayed back to provide air-cover to those within the pod. For the system we had to maintain/develop they stepped up to satisfy whatever business requirements came our way as well as handling any emergent technical problems. Gratitude is owed and deserved.

Technical Leadership Vs Bottom Up, Organic Adoption

I’ve heard of a case at a different investment bank of someone fairly senior decreeing that development going forward needs to be done using Clojure (I disclose now that I don’t have all the facts). I’m not sure how I feel about the idea of this. On the one had it feels good that someone high up has got a kick-ass mentality to drag up the quality of the tools that people in the trenches are using to eliminate waste and to speed up development. On the other hand I can see some people getting frustrated – i.e. not everyone wants to get bloody on the cutting edge and to call themselves Lisp hackers, having to revert from the cosy wizardry of professional refactoring powerhouse tools like Eclipse/Intellji to having to use Emacs or Vim, tools of old.

Changing from a statically typed OO language to a dynamically typed FP one is a fundamental change requiring lots of organic support and I’d be interested to hear if it can be forced or not. Maybe it can be. Maybe this is good. There’s also still immaturity around the Clojure tools ecosystem to grapple with. Nrepl is replacing Swank-Clojure, Lein 2 is about to be released which is a major upgrade. Although you can get copious amounts done using Clojure one has to say that the ground still has the occasional tremor and this may affect bringing onboard the masses. I would expect that there is lots of devil in the detail around Clojure mass adoption.

At our bank we were given some room and trust to take technical decisions so long as our cost/benefit case was solid. It felt right for our team at the time to start using Clojure – we were not instructed to do so.

Support from the Business

The Business were typically not as patiently supportive as our technical stakeholders. However pleasant our business customers are there’s always an element of ‘why we have got X amount of the team diverted away from serving the direct requirements of the business to do tech stuff?’

It may sound obvious but the only effective way I’ve found to deal with this is get a synergy between the ‘tech stuff’ and needs of the business as soon as is reasonable. Our pod of Clojure devs made a switch from straightforward 100% reengineering to doing a mixed blend of new requirements for the business too. Now the business are happier and we get some relief. Since development is more productive around our new infrastructure we can turn around long standing requirements for them faster and it’s fun to do. They will reap the rewards from here on in.

This does however mean that we’ve increased the amount of work we’ve signed up for and overall pressure on ourselves, this has affected our morale. We are currently sailing quite close to the wind with anti-patterns ‘scope creep’ and even at times ‘death march’ hovering. There’s no doubt that we’ve had our share of stresses and that there are more to come. I can though take some comfort that with hindsight the thought of sticking with the old status quo of a monolithic Java app does not become any more appealing. Eventually the waste will crush no matter what the resources of an institution.

§ 2 Responses to Clojure at a Bank – Support

  • Stacy says:

    So basically the business doesn’t want to invest in its future and consequently you’re pushed into a near death march !?

    What if this intolerance of investment (i.e. sinking some money now for a return later) is the primary cause of the Java model being so poor (I’m no fan of Java btw) ?

    I think ultimately the business has to agree to a sustainable development pace, sustainable meaning producing at a given rate (quantity / cost, where cost ~= time + morale + quality) endlessly. They should also agree that a past unsustainable pace (i.e. one that demanded an increased quantity, reduced morale, reduced time, reduced quality) is the cause now for an anomalous correction, i.e. spike in investment. If they think they can get out of a situation caused by mal-investment with more of the same they are idiots.

    On the other hand perhaps they simply don’t believe that it’s a temporary correction, maybe they were told the Java work was an investment. If so then I think you should work to establish more credibility.

    By signing up to the same rate I suggest you are agreeing with the business that: they don’t need to pay for prior mal-investment, you do or: the new work isn’t an investment, i.e. will not yield a return to a sustainable + better rate of production; both of which works against your credibility.

    Lastly why do you feel pressure ? Does signing up == committing to == agreeing to unpaid overtime == charity for billionaires ?

  • Jon Pither says:

    Hi Stacy,

    Thanks for the comment. Like most banks in the current climate there has been lots of change at our current workplace – in particular key technical and business stakeholders have rotated in and out. Therefore I find we’re often having to restate our case. Communication is an ongoing effort we have to do and we’re not always perfect at it.

    I completely agree with you about the need for the business to agree to a sustainable development pace. Getting people to see the bigger picture again comes down to constant communication. Sadly at a such a large institution different groups of people have different priorities – not everyone is pulling in the same direction all of the time despite the organisations best efforts.

    IBs (investment banks) are a challenging place to work at and frankly they come with lots of stressful imperfections. Worth experiencing IMO but not everyone would want it. I agree with pretty much all what you say but we’re not giving out charity to the bank :-) One has to draw the line somewhere.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

What’s this?

You are currently reading Clojure at a Bank – Support at Pithering About.

meta