Clojure at a Bank – Clojure Code Immaturity

November 4, 2012 § 13 Comments

I’ve posted recently about a team at an investment bank wanting to make the transition from Java to Clojure. Here I want to write about some of the issues around our Clojure code being ‘immature’. Before I do though it’s only fair I state up front that not all of our early code was terrible, Clojure is indeed a pragmatic language where you can write decent and understandable code relatively easily. Still..

Comments and LOC

Most of the devs on our team have a TDD/DDD/BDD background with half having once plied a trade as XP consultants. Our approach to writing beautiful Java code was to make it flow and to tell a story. Expressive names for classes, methods and variables, each chosen to convey clarity and meaning to the fortunate reader.

Therefore when we jumped both feet into Clojure we unconsciously brought with us the belief that comments just weren’t needed. Add in to the mix that we gave our args the shortest possible names – most of the time just single characters – one could argue that we purposefully went about trying to obfuscate what we were writing.

Then to make our code more fugly, we executed the common newbie sin of not really knowing what’s in Clojure.core but churning out bucket-loads of FP code anyway. For example we had a brave early attempt to get around assoc-in not being able to work with nested vectors as well as maps when it actually could (assoc-in m [:key1 0 :bar]). This led to some funky code existing in functions with interesting sounding names like ‘weave-in-vectors’ – the choice of naming being a sure fire smell that there must be a more idiomatic way of doing things. Then there’s the little stuff: ‘if’ and ‘let’ vs ‘if-let’, ‘let’ as its own form rather than embedded into a ‘for’ as ‘:let’. Then there’s zipmap, juxt, mapcat, group-by… a considerable list of helper functions that avoids us having to write our own cruft.

I also have to own up to having a personal fetish for a low LOC wanting it to compare ever so favourably to the old Java stack that preceded it. The cost was that some people wondered wtf some of my code did but at least there were few lines of it. There’s got to be some prize for that, right?

We matured past these issues by communicating amongst ourselves as we found better ways of doing things and thankfully we had a team where criticism was generally well received. Clojure itself is an opinionated language and when you’re coding in a more idiomatic way the pieces of the language tend to fit more easily together. Idiomatic = more graceful/simplistic. Don’t say to a colleague: “Your code is shit”, do say: “There’s a more idiomatic way of doing this”. StackOverFlow and blog posts are full of examples of how to write more idiomatic code for particular use-cases and the Clojure Google Groups are good also.

Namespaces

In Java/.NET development we now have extremely powerful tools that help you to navigate your way around a large code-base – i.e. Eclipse/Intellij for Java. As the amount of class files inexorably grows it never really seems to matter and you just get used to it. (Here’s a controversial Recursivity blog post entitled “IDEs Are a Language Smell”).

In FP a single namespace will nearly always contain much more logic than compared to the average OO class. Since you’ll be spending more focused time in fewer files this then creates a need for namespaces to be presentable. Comments at the top can be helpful, they should have fewer public functions, and they should be split up if they get too large – we’ve occasionally split out the cruft from a namespace into an accompanying ns-utils.clj to make the main one clean. We’ve also reapplied various bits of DDD and OO to model namespaces around business domain concepts and to keep them well encapsulated.

Then there’s (:require) vs (:use). (:require) is much better as each dependency usage is clearly marked with a prefix so you can clearly see where dependencies are used. This is kind of obvious but in the early days we used (:use) in most places – without only – and now we’re having to go back over and correct. Note that we did play around with using lein-slamhound for optimising our namespace declarations but then we found that the kind of namespaces you typically want to use this on need restructuring anyway.

Macros, Protocols, Defrecords

Having fun with macros is a right of passage. Some people passionately detest them whilst others enjoy using complicated solutions to solve complicated problems. I’ve learned that if I’m going to build a macro then it helps to keep it minimal and to delegate out the logic into a separate function relatively quickly. We once had some special code eval’ing deftest forms to generate tests based on some data that we had saved up. The idea was that the auto-generated tests would then play nicely with lein-test and consequently our build server. The trouble is that arguments to macros have to be serialized and you’re limited in by this, not to mention that the code can become that much harder to follow. By looking under the hood at what the deftest macro actually did – basically registering test functions – we replaced this little mini-framework of macros and evals without much fuss and it gave better performance in return (we stopped reloading the same data twice, once to register the tests and once to run them). Macros are helpful and powerful but they come with a cost.

Protocols are like having an extremely awkward member of the team around; someone who can get stuff done with an air of awesomeness yet at the same time you’re wondering if there is just isn’t a simpler way. They have some quirks setting them up and it’s added complexity, but on the whole I have to say that Protocols have been good for us. We had some hairy areas of the codebase where we were doing concurrent operations passing around a lot of functions, partially built up or otherwise. Introducing Protocols allowed us to pass a family of related functions around together as one thing with some immutable state. In a different area of the code-base they also laid down some hard interface definitions. We didn’t strictly need them for this purpose but enforcing a little of compiler-checked OO felt like a good thing.

Defrecords were primarily introduced for performance reasons. Where we were creating lots of little map instances we switched to using simple Defrecords instead. I would also argue that they forced us to think a bit harder about our modeling of data and use of simple data structures, leading to cleaner code in some areas.

Wrap Up

In my opinion figuring how to write Clojure code that is more idiomatic and simplistic is what makes Clojure fun, along with the fact that Clojure is blistering pragmatic. The learning never stops.

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.

Clojure at a Bank – Moving from Java

October 23, 2012 § 7 Comments

An increasing number of large institutions are now wanting to leverage Clojure. Large institutions are inherently complex and can often be dysfunctional in various areas. They do however attract lots of very good people and good people often bring with them the best tools.

Investment banks in particular have hard problems to solve. The financial instruments themselves have varying degrees of complexity, although whatever complexity they have often pales in comparison against the systems ecosystem that maintains them. I said once to a senior manager at one place that the number of systems I was seeing in various strates reminded me of Darwin’s survival of the fittest, beasts coming in all shapes and sizes. He said I was wrong because in the wild animals actually die rather than live on to relentlessly cause problems.

Over a year and half ago I was a team lead on a medium sized development team running a strategically important middle-office system. We were 100% a Java team and we had some pretty good devs onboard with decent backgrounds. We had plans to split up our Spring/Hibernate 1 million LOC behemoth and were getting in some decent wins to make this happen. Then I persuaded a Swedish colleague I’d worked with before to come work with us. I had the feeling the team needed someone to come in to and give us a kick and to challenge our general direction – he certainly lived up to this. Large scale refactorings I was fairly proud of he denounced as ‘just moving shit around’. If we were serious about changing our system then the only way to do this was to change our course radically. Although he was challenged fairly robustly – to the extent that at times I know he got quite pissed off – a few things we were already conscious of.

Firstly Java encourages lots of modelling. “Let’s sit down with all the power of OO and create of lots of classes that attempt to model the problem at hand. We won’t use UML but instead we’ll evolve it in an agile way.” The model in the investment banking world is actually quite complicated so this OO graph grows quite large. Abstraction is brought in do deal with variance; abstract classes and interfaces proliferate. The type system encourages this. I had used some dynamical languages before and it was quite obvious that we were essentially forcing lots of schema and type definition on to a problem domain that just didn’t want or need it. Sure you can minimize the pain with patterns such as composition over inheritance, better abstractions etc, but we had already admitted to ourselves in some quarters that we were fighting the wrong battle.

And soon it becomes like wading in cement. Our system was predominately conceived around 2007 when it was the heyday of using Test Driven Development (TDD) and to have a heavy reliance on dependency-injection frameworks like Spring. I should state now that I don’t actually dislike Spring with any religious fervour – it just looks redundant in retrospect now that I’m working 95% with FP code. Our app back then also had lots of Mock framework usage – we had both JMock and Mockito flavours. Before our big move to Clojure I’d already decided I just didn’t get on with mock frameworks. They slow down development as you constantly find yourself fighting against lots of incomprehensible tests written dogmatically that rarely test anything useful. I really can’t really think of many situations right now when using Mocking would be a good idea, even in a Java/OO setting.

I had also picked up a consensus view amongst industry peers that the only way to truly break up a big monolithic system like ours was to enforce hardline decoupling around service boundaries. The best way to achieve this is naturally to use different languages. If we’d have stuck with Java we’d never have ‘gone for broke’ to drop a crowbar into our system and to wrestle it apart. Now we’re using Clojure this is essentially what we’re doing, and not in a bad way.

You also need to ask yourself when contemplating a fairly seismic shift of tool usage what about the business? What about the stakeholders? Who is going to pay for this kind of re-engineering and why?

In the end there are a lot of answers to these questions. My answer of choice tends to be waste. Waste on the scale lots of project have should not be tolerated. Waste in terms of time spent wading through cement-styled Java, time spent hunting through layers upon layers of indirection, interfaces, unit/integration/acceptance tests, Spring XML files, just to find the one if-statement that actually has some business significance, Eureka! We had/have waste on a fairly large scale and to start developing our system in a fundamentally different way almost seems the only sensible option especially if you want people to stick around.

Here are some specifics – our new code is going to be an order of magnitude less in volume than the old and this is being conservative. With the new code you can use your REPL to navigate in and to run any little bit of it you like. You can change any code and see the changes immediately in your browser (our app lives inside of web-server instances) or REPL. Instead of modelling the world, every man and his dog, we’re going to instead write code that operates against simple data structures. If then we need to be able to determine what is actually going on – wtf – we’ll add lots of introspective abilities to our code. In short, to replace copious amounts of Java code along with built up DSLs that only devs use, we’re going to build a simple rule engine. And we’re going to provide some visualisation tools so that you can actually see the rules themselves. A rule editor may follow.

Sure we had lots of debates about why we couldn’t do what we need to do in Java, and in the end it became clear that you couldn’t really have the debate on these terms. The decision of switching to Clojure fell in to three natural brackets. 1) What’s good for the long term nature of the project? 2) What’s good for this present team? and 3) What’s good for the individuals involved? 1) FP seemed a better fit for our system – it’s basically functional blocks of code hanging of financial market events. Our system also suits a dynamic language making all the rigid schema definition less of a problem. On a different tack surely the long term view project is best served by using the best tools and being able to attract the best people. 2) The team will be motivated learning something new and we’ll likely get better retention. This is ultimately good for the costs of the business. 3) The majority of the team wanted to try Clojure. As Hakan made the point – we don’t get paid to enjoy ourselves at work, but it doesn’t hurt. It’s an obvious point – a happier team is more productive.

In the end at some point a team just has to take a jump. Certainly there’s been problems and long standing issues in our move to Clojure and there are some significant questions still yet to be resolved. We’re a global team and this brings with it a wealth of complexities. A year ago we were also a bunch of Clojure newbies finding our way and some of our code and decisions reflect this. I’ll write about these in a subsequent post.

Year of Clojure at a Bank

October 22, 2012 § 2 Comments

We’re roughly coming up to a year anniversary of when myself and a ragtag bunch of pan European devs started to use Clojure for our day jobs at an investment bank working on on a strategically important middle-office platform. Hakan Raberg is the change agent that when joining the team argued the case for moving to Clojure to whom I am indebted. Hakan and I did a talk at EuroClojure talking about the project – video here.

We’re also going to talk this week at FP Day in Cambridge. Here we’re going to address ‘Clojure after the honeymoon’. Here we want to give an honest account of the problems we faced introducing Clojure inside somewhat of a conversative environment, and of what is the current state of Clojure is. We also want to talk about some of the technical challenges we had particularly around making the jump from Java to Clojure. Hakan left the project to rewrite Emacs in Clojure and to widen his brain neural pathways even further, I’m still on this very project dealing with the fallout.

Time permitting I hope to write up some of our experiences talking about some of the cultural shifts and also about some of the technical stuff we did – i.e. our approach to regression testing, our Clojure rule engine, and the continued battle inside and out of a large Java monolithic beast. I’ll do this in a short series of posts.

Clojure deep-update-in

July 7, 2012 § Leave a Comment

I needed this the other day and wondered if it would help others or if there’s a better way.

There are two functions. The first goes looking for a key anywhere in a map and produces a sequence of key-paths that can be used with get-in, update-in and assoc-in. Note this code only recurses into substructures that are vectors or maps.


(defn find-key [ks k m]
  (cond (map? m)
        (reduce into (map (partial conj ks) (filter #{k} (keys m)))
                (map #(find-key (conj ks (key %)) k (val %)) m))
        (vector? m)
        (reduce into '() (map #(find-key (conj ks %1) k %2)
                              (iterate inc 0) m))))

The deep-update-in uses the above:


(defn deep-update-in [m k f]
  (reduce #(update-in %1 %2 f) m (find-key [] k m)))

m is the map, k the leaf key you're looking for (a single key, not a path of keys), and f the function you want to do the update.

Thoughts on Self Organising Teams

April 26, 2012 § 1 Comment

Notes: 1) I wrote this post a year ago before I mothballed this blog site and lost my domain name. I’m not really wanting to get back blogging often but I have a couple of things I want to write about in the medium term. 2) Ironically the team I’m presently on and the one I used for the basis of this post has drifted into a non-sustainable tactical mode that isn’t enormously self-organised – I talk about this at the end.

I’ve written a couple of posts on Self Organising Vs Managed teams in the past. Over the last year I’ve had the good fortune to work on a team that is predominately self-organising, and wanted to write up the main learning points that stick out. I’ve written this from the perspective of facilitating a self organising team. This is also against a backdrop where a dev team has a high degree of ownership over its codebase, and is of a small to medium size (around 10-12 people). If the conditions aren’t right to begin with, then it often doesn’t matter if a team is self-organising or not.

Organising Self Organisation?

The first sub-topic to address is the meta. That is of how much should you organise a ‘self organising’ team. I once worked on a team where the PMs thought that a strong dev team would somehow ‘grow’ out of the various developers they had scattered around a room. Like monkeys and typewriters.

And of-course it really didn’t work. Deadlines missed, low morale, software written to a dubious and inconsistent standard. I’m sure the project managers who were there at the time would now say that the project was successful and use it as a highlight for their careers, but the fact is that the whole thing sucked massively, almost comically so.

Staying with monkeys and typewriters, of course if you have the right monkeys then they should be allowed to crack on and solve the problem they are there to solve. But where this works there is usually some kind of organisation in place, no matter how subtle and transparent  it may be, and we’re talking about a team consisting of seriously good monkeys. A rarity.

I know that on the face of it the idea of organising a self-organising team sounds contradictory, that a self-organising team should surely lack any sort of dictatorial or outside behavorial influence. But I do think that there needs to be some founding principles at work. Just like tolerance needs intolerance of intolerance, I think a self-organising team needs some organising to be self organising.

Good People

I’m not someone who has reservoirs of faith and patience for being able to work with just any plucked-out-the-ether developer. And if I’m honest this was one of the hardest things about being a consultant, because that’s exactly what’s expected of you. I’ve worked with many developers who simply just shouldn’t be developers. I’ve been on projects where I’ve spent most of my time refactoring and deleting code written by others and just hoping that I’m going faster than they are as to have some kind of net benefit.

The reality is that if you are tasked with running a team and you want it to be a ‘strong’ team, then you really need to ability to hire and fire. You need to be able to populate the team with the best people that you can get your hands on. If you don’t have this level of responsibility and you’re told just to suck it up and work with whoever, then you’re really up against it. In a team you need leaders and people with exemplary skills that inspire others to up their own skill-sets and abilities; everyone working together to help each other along. You also need people that are fun too, and everybody in the team needs to be generally easy to get on with.

Challenges I’ve faced include having to convince business stakeholders that developers are not a commodity that can be easily swapped in and out. It’s a battle that’s never really won as stakeholders come and go, and usually they never lack conviction in their own opinions. Talking in terms of objective evidence and waste/risk helps, and this is where a team facilitator can play a useful role. Another challenge is making sure that inevitable attrition is mitigated, however tough it may be to do so.

Empowering (Delegation)

It just so happens that if you’re tasked with facilitating a team populated with bright, good people, then you’ll probably find that for any given job they’ll be someone on the team who is better at doing it than you, or more likely, has the drive to do it.

I’m consistently and pleasantly surprised by the varied skill-sets of those around me. There are people with quite finely-grained nitty-gritty problem solving skills, then there are others who possess a natually gifted systems-overview way of thinking. There are those adept at getting close to the business and understanding their wants and needs, and conversely there are those who see the business as dark hooded figures, whispering and scheming on the sidelines.

The point is that when working with creative, intelligent people, then the job title changes from that of leadership to facilitation. I’ve little doubt that certain circumstances call for the type of robust expletive laden leadership offered by Gordon Ramsay in his kitchen, but where there are highly skilled people involved such as in the software delivery industry, then this approach doesn’t really work. You let people who are able to solve complex problems get on and solve them. As a facilitator your job is to help make that happen by mostly getting out of the way, or to muck in and help if your contribution as a task-executor is useful.

I’ve worked on a team where the facilitator wasn’t a Gordon Ramsey, but was instead a wannabe primary school teacher. ‘Have you written a FIT test?’ That’s good. ‘Have you you asked the BA about the requirement before starting work?’ Ha-ha! Just checking. It makes you want to just tell someone like this to get out of your face and to basically fuck off.

I think as a team faciliator you need to be able to trust someone to do a job. But admittedly there are subtleties. Knowing who has the relevant skills for a particular problem helps, and trying to avoid the situation where only he/she can do a certain job also helps. Some people enjoy taking on responsibility and a degree of accountability, others would rather get on and code. Making suggestions about what certain people could work on if they wanted to is not an altogether bad idea.

Mouthy Team

You need a ‘mouthy team’. The Agile stuff of retrospectives helps, and perhaps more so does the location of the office-place with respect to nearest agreeable pub. Really though, it comes back to having good people in the team. The team needs people who can challenge ideas and practices, to offer an opposing way of doing things that works.

You then also need people who can take critism, including yourself. Team members need to be able to watch other team members piss all over their best and brightest ideas. Not everyone is tactful about it – we are geeks after all. If instead you want people who’ll always listen attentively with words of support, then you can always hire consultants.

Sometimes a decision does need making, particularly in murky waters where there is much contention. In this case it’s about getting buy-in from the team and choosing a direction people are happy with, even if people acknowledge that there’s an element of gambling. I’ve read that this is a drawback of self-organising teams – inertia of making strategic choices – but I’ve rarely encountered a situation where competing views jostle against each other and logic doesn’t win out to pick a solution. If you have personalities in the team that stick to a position and refuse to budge despite logic and evidence… then either feedback needs to be given or the topic of ‘hiring and firing’ needs to be revisited.

Energy

Energy is something a team facilitator can bring to the table. Whether it’s keeping a stand-up on a Monday morning upbeat, organising team lunches, or encouraging brown bag sessions and tech talks. The facilitator may not be the person that comes up with the idea of a particular technical talking session, but they should be able to make it happen if someone feels it’s important. The facilitator should also be able to cope with the more mundane stuff that needs doing. Someone needs to plan meetings such as iteration planning meetings, kick-offs and retrospectives. Some of this can be delegated to those that enjoy this kind of stuff, but it needs taking care of. Some are better at this than others.

Management Support

You need a good manager to give the team some space by which it can become encapsulated and be to judged on its results. The team must also be supported in the occasional battle (i.e. the prioritisation of technical platform work over business requirements is a popular one). At the same time managers must resist from standing completely back and allowing teams to self-organise themselves to effective failure. There is also people rotation to think about – why should one team have a set a talented people in contrast to other teams, shouldn’t they be shared around? Spare a thought for the beleaguered manager, his/her job is never easy.

It’s not a religion.

As I said in the notes at the top, the team I’m currently in and had in mind when I wrote this post has drifted away from being self-organising, and has gone into more of a non-sustainable tactical way of working. If people are happy to, when you’ll attempting to climb over a large challenge then sometimes you have to tolerate silos and to ask people to stay in particular work-streams for a short duration. It’s not ideal and you need the backing of the team to do this, but sometimes going tactical to get shit done can be fun too. The trick that we haven’t attempted yet is to crawl back.

 

White Paper: An Agile Approach to Modernisation

November 1, 2009 § 3 Comments

Update: Very annoyingly ThoughtWorks redid their website and my whitepaper and those of others were removed. Here it is.

I recently wrote a white paper and it has been added to the ThoughtWorks collection of white papers here: http://www.thoughtworks.co.uk/what-we-say/white-papers.html.

After having been involved in a few projects whereupon the client has a need to modernise an ageing technology stack, I thought I’d pull together from these experiences (and from those of some helpful colleagues) and do a write-up.

Here’s the abstract:

Gartner makes the prediction that by the end of 2010 ‘more than one-third of all application projects will be driven by the need to deal with technology or skills obsolescence’. The process of refreshing technology platforms – Modernisation – is one that is fraught with risk. From spiralling complexity to software development teams losing business focus, there is ample opportunity for a modernisation agenda to fail.

This paper has been written for the non-technically minded business and information stakeholder without prior knowledge of Agile. It looks at using principles and practices originating from the Agile philosophy for mitigating the modernisation process.”

The actual PDF can be downloaded here: http://www.thoughtworks.co.uk/pdfs/agile-modernisation.pdf

Thanks to Liv Wild and Simon Brunning for peer reviewing, and to Davie Moston and Gaurav Sood for giving me feedback on its various incarnations and iterations.

The DEFCON Door

July 28, 2009 § Leave a Comment

This is a post about the practice of risk management through use of a ‘DEFCON Door’.

A DEFCON door? Well if you’ve seen that early 80′s film ‘WarGames’ starring Matthew Broderick, or if you simply know your US history, then you’d know that DEFCONs – Defense Readiness Conditions – are used to be a “measure of the activation and readiness level of the US armed forces” (as described on wikipedia). During the Cuban missile crisis DEFCON 2 was reached, with the US airforce readied up to go and bomb their cold-war rival the USSR.

And how might this be applicable to your typical day-to-day IT project? For starters, once on a project what we did was to find a spare door and to configure it as such:

Defcon Door

It’s very simple really. Along the top column headers are the various DEFCONs. DEFCON 1 would mean that it is the consensus of the team that the project is going to fail because of a particular issue; that a very serious risk has indeed materialized. DEFCON 2 risks are still very serious, and DEFCON 3 ones are merely lesser risks that the team feel are important enough to warrant exposure at a particular given time.

What I found most pleasing about the DEFCON door was that it seemed to be a fairly natural extension of the Agile software development practice and was therefore well-adopted by individuals on the project. For instance in a similar way to how we do story estimation a person would read out a ‘risk card’ and then the team would count to three and display with a finger count the the DECON level that they thought the risk had reached. No fingers at all meant that the risk could simply drop off the door altogether – which ought to be a good thing.

Normally every couple of days or so after the standup we would do a quick review of the door. Sometimes, we also did it after a retrospective, because a few things that had been brought up were indeed risks that the team thought were ‘DEFCON appropriate’.

Risks would sometimes traverse up and down through the DEFCONs as the team would attempt to grapple with them, and often risks would be broken up into multiple risks, or instead merged together to form all encompassing ones. No one team member should own the door as it works very well as a collaborative tool where everyone can have input.

Thoughts on effectiveness:

I think often individuals within a team will have very real concerns about some particulars of a project. Personally speaking, one of the wants that I have when I have such concerns is that my concerns will be listened to and registered by the team, and I think the DEFCON door to an extent gives you that.

It also brings the team closer to the risk tracking that would ordinarily be done by project-managers. Although I don’t think it should be a replacement as it best works as a lightweight tool, there’s real value in having team-members contributing to tackling and identifying risks on a day-in, day-out basis.

The DEFCON door also has uses outside the immediate vicinity of the team, such as the ability to show project stakeholders the door and say “these are the major risks that the team feels are present right now”. Often stakeholders not operating within the team will have a want to gauge a collective opinion about how the project is going and the challenges that are being faced. Here the door can play a useful role.

Potential Challenges:

Firstly, it sometimes can be difficult to locate a usable door, especially a nice wooden one. If need be you could use a wall, but then you’d be harming the linguistically pleasing flow of the “DEFCON Door”. It is however, really up to you.

Understanding what the scope is of the door can be at times slightly difficult. For example it can be tempting at times to throw up enterprise-wise risks up on the door that are not directly project-related (e.g. is this architecture appropriate for adoption by the wider organization?). A strategy a colleague of mine came up with is to have a DEFCON corridor, but I fear this may be over-egging the solution. I would endeavor to keep the door simplistic, and if the door identifies risks and questions to be managed elsewhere then that can only be a good thing.

We should also note that this model of risk management is very lightweight and simple, and that there is much more about risks than can easily tracked and measured on the door. Therefore it would seem appropriate to use it to augment a more sophisticated risk management process.

In conclusion, the DEFCON door is a simple tool that aims to bring risks explicitly into the highly visible and participatory realm of an empowered, self-organising Agile team.

The downside of Agile

July 18, 2009 § Leave a Comment

A post I wrote three years ago but never published, I was pissed off back then after a couple of lousy gigs in a row. This was me coming out of the bright eyed Agile love affair mentality a lot consultants have.

Looking around the IT industry at the moment (or rather the microcosms of it that I’ve had exposure to), I’ve begun to develop an unfortunate degree of cynicism about the widespread adoption of Agile.

Currently there are people making claims that Agile has finally passed the chasm; that light has indeed been shone upon the masses. The more cooler of kids will of course have moved on to pioneering something else (maybe Lean), but Agile generally is where it’s all at. If you’re a conservative CIO waiting for something to come out of beta, then the wait with Agile is over.

But – and the more cynical than I would have clearly foreseen this – this widespread adoption is going awry. Namely, that when Agile techniques are ‘leveraged’ in the way that traditional software processes are, the sort of problems that those in position of management thought they’d seen the back of come back to bite, and harder. Problems such as low morale, lack of individual ownership, late delivery and runaway budgets.

Modern Agile methodologies (XP, Scrum) do indeed tend to offer a higher degree of transparency. But transparency itself invites meddling from those able to manipulate the process. Readily availability of metrics such as ‘velocity’ measurements essentially provide the grounds for managers to increase the amount of management. Metrics allows for targets to be set, and for endless tinkering to ensure that the targets are reached. The trust engendered to individuals to do the best job they can is lost when sophisticated charts come into play.

This is at the root my concern. That the previously existing command-and-control, blame-assigning culture of IT organizations simply carries on under a new fashionable look. In fact one might postulate that since Agile facilitates broader intervention at the various stages of software development, then Agile can actually increase the amount of bureaucracy directed at a development team.

And we must ask the question of ‘is this really such a bad thing?’, and am I just blowing this way out of proportion? We surely ought to welcome transparency and the safety nets that Agile practices layer into software development… Aren’t I sounding like the developer who wants everything his own way (perhaps) against the grain of the greater good?

Software is not simple brick laying. You can’t, as much as you might want to, trivialise it to the extent of paying a load of hot-swappable monkeys to write sonnets. Writing software is challengingly complex and has an infinitely diverse problem set. The solution requires innovation and that clever thinkers are given the time and space to follow their best judgment.

I have an inkling that some might feel I’m being somewhat unfair to the understanding of what Agile is really all about. Agile is simply a philosophy after all with axioms such as ‘people over process’ and ‘working software over comprehensive documentation’. The Agile manifesto itself doesn’t directly dictate how a software project should be done.

Well yes this is true. But then this is the difference between what an innovative approach is meant to be used for, and of what the collective wisdom of the masses decide it’s to be used for.

Without a deeper understanding of what a methodology is all about – or the bother to discover what it’s all about – managers will seek to use popularised yet blunt ‘Agile’ techniques to manage more, and then the whole ideal of empowered individuals/teams comes second or third. At worse the adoption of Agile simply becomes a guise for management by checkboxes. Got pairing? Tick. Got ‘stories’ in place? Tick. Got iterations? Tick. Not quite working? Oh well, let’s adjust the amount of pairs in team X, change working hours, assign workers to particular areas…

The lack of the masses understanding what Agile is all about is its downside.

An Intro to Non-Violent Communication (NVC)

June 13, 2009 § 2 Comments

What’s it all about? It’s easy to communicate without violence isn’t it? One would have thought that the majority of us would be able to convey a linguistic subtlety without having the need to head-butt the other person in the face (unlike some of my neighbours, but then that’s a different story :-)).

NVC is about communicating without getting people’s backs up; their heckles raised. It’s the ability to enter into a discourse with compassion and empathy, and to uncover what the real wants are that people have during a conversation, including those that we have for ourselves. And while it may seem like it comes naturally to some, it’s actually very difficult for the vast majority of us. In society we’re conditioned to think in certain ways, for example to judge and to offer our immediate evaluations; we are unconscious of some of the blockers that we have towards effective communication. This results in an inherent violence that stirs in each of us.

So what specifically is NVC? Thankfully it’s actually quite simple. It’s a four-step process. I’d ideally advise people to pick up a book on it, as it’s one of those things you really have to take on board and to heart, rather than to simply acquire an intellectual grasp of the concepts.

1: Separate observation from evaluation

It’s habitual for many of us to combine observations and evalutions. For example, if my wife tells me that I always leave the place looking messy, then I’m bound to feel defensive about that. “No, I don’t”, I’d probably say, “I actually spent a couple of hours doing some cleaning at the weekend”. I’d feel attacked, and bad mood for both myself and my wife would probably ensue.

But if she were to state that there were a couple of socks on the floor in the bedroom, then I probably wouldn’t really have much of a feeling about the situation at all. I’d likely instead develop a want to pick up the innocuous pair of socks, and I might just darn-it go and do it.

Confronted with an evaluation, we typically either defend ourselves or submit. Confronted with an observation, and it’s a different story. According to the Indian philosopher J. Krishnamurti, the ability to separate out evaluation from observation is the highest form of human intelligence. Does it always rain in England? Or did it simply piss it down last year at Wimbledon? (2007 rings a bell)

2: Feelings

When you communicate, state your feelings. I feel X about Y. I have to admit, I’ve found the acquisition of this particular skill to be particularly difficult. Why? Because for a great many of us we haven’t really delved into the workings of our emotions. I don’t always know if I’m feeling mostly angry, mostly frustrated, irritated or even aggressive (life on the London tube does that for you). Like when I taste a glass of wine, what’s actually at play here? Is it the vintage, the oak in the barrel that it was fermented in, the field it came from, or the blend of grapes? There’s a lot going on in people’s minds that it can become difficult for us to categorise our various emotions and to label them.

People can spend a lifetime in the pursuit of unpicking their various emotions (Buddhist scripture states that there are eighty four thousand negative emotions alone). In the west we’re starting to label the ability to recognise one’s emotions as Emotional Intelligence (EQ). People also use the term ‘awareness’; e.g. are we aware of ourselves?

So communicating a feeling requires an awareness of the feeling in the first place. And it can be remarkably powerful. If I can be aware, open and honest to state what I’m feeling, then I invite empathy. If my wife were to say to me “I’m feeling a bit frustrated with the state of upstairs”, rather than “you’re pissing me off leaving these socks around”, then I’d probably have a connection with that. I’d understand and gain some empathy for the emotion she is experiencing, and I’d likely develop a want to do something about it.

As I said it’s difficult. At work one time someone asked me why I seemed a little down, in contrary to how I was when I first joined the project when I was more upbeat and positive. Rather than state my feelings of frustration at my apparent inability to influence some positive change fast enough, I defaulted to bravado. What me? Nah, I’m cool…. honest. I’m a bad-ass ninja-type character. Seeing as the person asking me about my feelings was an influential person on the client-side (I’m a consultant), it was an opportunity missed.

3: Needs

I really like this part of NVC. Like the all 4 components of the methodology, it’s an independent skill that one can muster (and is therefore in-turn measurable by the lovable Dreyfuss model of skill acquisition). I wanted to call this skill “needs based thinking” as I think it’s so powerful.

If my wife were to say to me “I’m feeling frustrated as upstairs has some clothes on the floor, and I have a need for the place to be tidy this weekend so that we can enjoy it”, then we’re really on the money. I know some more of what her needs are, and I therefore know better how to meet them.

Frustration, some people say, is the feeling one gets when their needs aren’t met. A big personal realisation for me is that I’m not totally aware of all my needs. I didn’t quite appreciate my need for engaging with others, having challenging intellectual skirmishes, my needs for adventure, for approbation… (goes without saying that not all needs are admirable). I, like others, am a complex person with complex needs. If I can identify them better, them I’m sure to have a happier life right? Conversely, one should ignore their needs at their peril.

It follows therefore, that if I can communicate them, then there’s a much greater chance of having those needs met. I’ve found that when I’m honest about my needs to others (without wrapping them in bravado or dressing them up likewise), then I tend to get some compassion back.

4: Making a request

So, now I know that my wife is feeling frustrated because there are some clothing items on the floor in the house upstairs, and that she has a need for the place to be tidy so that she enjoy the weekend. Great. But what I really want to know is what the next steps are. Thankfully in this situation I can infer that the action item should be to get off my arse and to pick up my clothes.

But it’s not always this clear. I can reveal my observations, feelings and needs to others, but without solid requests we can’t be sure that the other person knows what to do to make a situation better. I’m anxious that we have more preparation to do for this presentation and I need to get a handle on it… any chance we can hook up tomorrow evening to go over some things?

In Conclusion

NVC is certainly challenging to embrace, and of course there’s a fair bit more to it that the quick primer I’ve just given. I myself am probably on the journey to becoming more aware of it’s impact, and am hopefully a little more “consciously incompetent” than “unconsciously incompetent”. I’m a novice, but it’s a communication technique that I really, really want to learn. If you’re interested, I’d recommend that a good place to start is by picking up this book:

Non violent communication