A tale of the rational allocation of resources under modern capitalism.
I’m a software developer; what’s known in the trade as an enterprise java developer. We usually write applications that unite lots of different technologies, and we usually try to do things the right way, so the code will be robust and maintainable, rather than just quickly hacking something out.
Trouble is, in software and technology, the right way is a moving target, and before long whatever you do becomes the wrong way (or the old way, just as bad). So we spend a lot of time revising our stategies in the light of experience and new technolgies. We also capture these lessons in what we call design and process patterns. So we write about all this a lot, and if you read the output, we take ourselves very seriously and sound very sober and professional.
Right now we’re all drinking the SOA (Service Oriented Architecture) kool-aid, it’s all ESBs (Enterprise Service Bus) and web service endpoints, Business Process integration/orchestration, asynchronous messaging, trying not to laugh as we talk about ‘potential for reuse’ (we’ve been using that turkey at least since Bjarne Stroustrup came up with C++). And wondering if we’ve thought about data transfer properly yet.
Anyway, I tend to work for the type of client who can afford this kind of enterprise development project – mainly consultancies, investment banks and other market players like brokers, clearing houses and central counterparties.
People who know my political instincts often ask how I can stand working for that type of company, that kind of evil, particularly the investment banks and market players I usually work for as an IT contractor.
My answer is that they have provided me with a first class education (all my training has been on the job), interesting work, good money and in nearly all cases have had absolutely nothing in return.
How does that work? I often work on fascinating projects that never go live, maybe they’re just proofs of concept, demos, or they get overtaken by developments in the markets or technology. Some projects die because they get caught up in board level knife fighting, used by executives to fence with each other.
Some projects die in consultancy wars, where one consultancy fights to edge another out of a lucrative project, with little or no regard for whether they’ll be actually able to deliver if they take over. This is often associated with board level conflict as allied directors and consultancies fight it out. Tens or even hundreds of millions of pounds can be pissed away on this sort of thing; teams of developers can be sitting around for months waiting to be told to do something.
Some projects die on outsourcing, and we spend ages trying to work out a process for working with teams in Bangalore or elsewhere. These projects spend a lot of time working out how everyone’s going to communicate and work together. Takes a while to get to the actual development, if you do. Then you can discover the outsourcer lied extravagantly about cost or ability.
Some projects die on technology choices. I joined one with a prestigious consultancy team working for a prestigious investment bank where we were going to use Model Driven Development, a whiz-bang new idea where we draw UML (Universal Modelling Language) diagrams describing the application, but not just one set at one conceptual level – nope, we’re going to do one set that represents the model in completely abstract terms, so that some bit of software we’ve never used before can automatically churn out a model for different platforms and languages, including the one we plan to actually use.
This is actually based on another another turkey we’ve been peddling for years, and in fact the thing that’s meant to happen next in this unlikely sequence of events. The code itself will be generated automatically from the model – a holy grail in my trade. Never yet seen it work in anger on something big and worthwhile.
Anyway, on this project, in the first week they decided, sensibly, that it’d be too much effort, so I got my notice. Except they gave me six weeks notice instead of the required one week, so I got to laze around for a couple of months soaking up trading flow workshops. And watching them use some flow chart notation, rather than UML.
Some projects have no real reason for existence at all, and we can procrastinate endlessly – technical testing, product evaluation, new tools and techniques… basically lazing around, invoking unneccessary complexity when too much pressure looms. ‘More analysis’ is the cry, or ‘more modelling’, or ‘we have to define requirements more clearly’,’we have to track change more efficiently’, ‘we need a better development process’, ‘add a dedicated persistence layer’, ‘use a different framework’, ‘aspects’ and ‘inversion of control’… and many other similar ploys.
I could go on. I suspect I’ve only been involved in delivering one viable system in at least two years, probably more, and that did something so pointless I could never feel guilty about it.
What a great industry.