There comes a point in a developer’s life where one develops a solid confidence in one’s opinions and actions. For me, this aligned with parenthood; the horrifying responsibility of being in charge of a little one’s life makes choices such as “which java based presentation technology shall I use?” a decision that can be approached with a lot more perspective! And this year I took another leap towards the “Definition of Me” when I agreed to submit a conference paper. My new-found confidence allowed me to submit a punchy title without fear of being unable to live up to it, and when my concept was accepted I began a fascinating journey through the history of my entire career and emerged with a comprehensive set of opinions and ideas that I didn’t even know were there. A highly recommended journey.
My initial concept came from a small set of technical problems that had been annoying me at the time. I’d been learning Scala and decided to try and use it in anger in a web environment, so created a RESTful API and stuck an AngularJS front end on to see what it looked like. I was hosting the two separately – AngularJS in its seeded http-server container, and Scala through a template Akka/Spray app in Typesafe Activator. Bang – of course, I hit the Same Origin Policy which wouldn’t let my AngularJS app talk to my Scala app when called from a browser. Thinking about why this policy was introduced and how it had been implemented got me musing on why it couldn’t be re-done in a better way now that our browsers and use of HTTP security features are much better. It was a policy implemented in haste to prevent hacker damage, which we can now all regret at our leisure.
Then fast-forward to my next project, we were building an ASP.NET MVC project which needed to communicate with a SOAP service – easy, right? Just create a SOAP client in ASP.NET? Wrong. The SOAP service was written in an old version of Apache Axis, and some of the types represented in the WSDL represented Java classes without definition and assumed a Java client! Yuck.
My final irritation was yet another one of those bugs where somebody has unwittingly loaded an entire database into memory through a misplaced Hibernate call and incorrectly-defined loading policies. For the X hundredth time I wondered whether we were really gaining anything from abstracting the power of the database and insulating developers from the complexity of mapping state to in-memory objects. A good long winge with a DBA friend of mine suggested that I was not alone in this muse! And a brief google search for “ORM anti pattern” confirmed it.
It was about this point that Java team lead Andrew Harmel-Law suggested that we submit some papers for the upcoming Devoxx conference. I had my recent bug-bears in mind and wondered about creating a paper called “Modern Antipatterns”, until I googled it and discovered it was the title of a hilarious poor-working-practices speech from a previous Devoxx. So I had to rethink. What was it about the two problems I’d hit? What did they have in common? Well, they were both things that made sense at the time, but were for whatever reason outdated in today’s architectures. This concept of patterns in time led me to my title: “Technical Archaeology – unearthing the dinosaur antipatterns in modern distributed architecture stacks”. Bingo! So, I submitted the title with a list of three “antipatterns” (Singleton, Same Origin Policy and Object Relational Modelling) and a very brief explanation, and forgot about the whole thing.
A few weeks later I received an email from Daniel Bryant, one of the Devoxx conference organisers. He wanted me to elaborate on my paper. Would I be able to talk about additional patterns in the presentation – maybe something slightly more complex for their more senior and advance-skilled audience? More complex how, I queried? Perhaps my use of the term “patterns” had been misconstrued. I didn’t mean GoF exactly - the “this-is-dated” angles on most GoF patterns are rather language-dependent - for example the visitor pattern is not relevant for functional languages, and javascript has the prototype pattern built in to the language. I was thinking of patterns at a more enterprise level and architectural level rather than diving into the complexities of a language. I offered a couple more pattern examples – the horror that was EJB 2.0 and my SOAP experience, and that clinched it for Daniel as he’d been bitten by the same axis bug. I was in!
The process of actually writing the conference speech was the real revelation for me. I had started with a title, and what ended up as five examples of “antipatterns”, and when I presented this to a demo audience it was clear that I needed more cohesion between my five examples. What was the link between them? What point could I make about the whole thing? I had to go back and drill down into my concept once again. I emerged with a few opinions that I realised I’d been formulating my whole career.
It’s interesting to watch the evolution of software engineering because it’s such a new discipline. It’s only had time to go through a couple of oscillations through trends. It seems to me that there has been a general trend towards “do everything you can”, the apex of which I would say was EJB 2.0 with a specification so heavy it could not be lifted, let alone read and digested. This can be seen in many areas of software architecture – look at SAP, for example, and the merge of the concepts of a portal website, content management system, document management system that we see in Sharepoint and Vignette amongst others. We are well on the way back down that particular trend now, with “do-one-thing-and-do-it-well” microservice architectures becoming more and more popular. I can see that there are drivers behind these trends – sometimes social, sometimes driven by a particularly powerful company or a particularly well-defined global specification but often driven by the underlying hardware available for processing and networking, and the algorithms that support them. What would the point be in a microservice if your network latency is huge? But now we have optic fibre cables and broadband and near-global 4G wifi, we can rely on messages getting from A to B in a reasonable timeframe. Similarly, why have a wireless camera take a 20 megapixel photo if it doesn’t have the algorithm to compress that picture to be sent?
My five patterns all fit well into this angle of software evolution driven by hardware over time. The singleton pattern was important and useful back in the day when you had a single CPU and your entire program ran on one machine. It doesn’t fit so well in a message-based architecture… The Same Origin Policy was implemented in the brave new world of internet commerce, when thick client browser architectures were immature and there were so many open doors for hackers they were spoilt for choice and a quick implementation was more important than a long-lived design. SOAP was a good advancement on CORBA, and at the time was a real step forwards in cross platform architectures, but because the specification became too broad in the “do everything you can” trend there became too many points where underlying implementations could differ. And at the time that the SOAP spec was written, there weren’t really any mobile platforms so the relative size of an XML message didn’t constrain the hardware at either end of the transaction. It reminded me of the human appendix, and goosebumps – things that had a purpose at the time and kind of hung around because there wasn’t a strong enough drive to remove them from the gene pool.
I then realised that if I was going to talk about evolution, I’d better explain a bit about what it meant to me. It’s a word which is often used outside of its dictionary definition. My favourite explanation is the one picked up in a speech given by Douglas Adams. “That which survives, survives”. Simple as that. Things (be they technical architectures or biological mutations) exist because they aren’t killed off by their environment – whether their environment is the African plains or the open source software playing field or whatever. This didn’t quite cover all the parallels I saw with the evolution of technical architecture and biological evolution, so I browsed through some books and papers, and found the two definitions I was looking for. Divergence, and Vestigial Functionality. All five of my antipatterns could be classified as dinosaurs for one of two reasons – either architecture had diverged away from those patterns, as in the example of EJBs and ORM whereby we are moving towards a simpler do-one-thing-well architecture and away from complexity and abstraction. Or, the pattern is what I’d consider vestigial functionality – as in the case of the singleton, which is a pattern based on single-CPU object oriented programming in a world where this is becoming less common.
I could feel this all coming together. I added in some demos of my Scala example and my SOAP disaster to keep people awake, tried to add some humour by asking my friends for some, and now all I needed was a conclusion.
I wondered if I could extrapolate out some prediction of the future from my musings on the evolution of software being driven by hardware. What was coming up in the hardware world? Bio-computers? I couldn’t see that necessarily changing software. The end of batteries due to lithium supply constraints? Possibly, however the more I thought about it the more I realised that I wouldn’t be able to make a useful prediction. There are so many variables, who knows which ones will be the “fittest”? I decided that a better conclusion would be to advise people NOT to try and predict the future, but just to be aware that things change. We often get in the habit of using something because we used it before. If you were to ask a technical architect to design a stack to host a website, they’d probably stick Hibernate in between the data source and the business logic layer out of habit. It’s this kind of behaviour that we need to be aware of – sometimes it might be valid, but sometimes things will have changed and the architecture of yesterday not quite fit today. I finished with the line, “Design for Disposability, not for the Future”. Done. I went off on holiday for a week to recover.
I returned to an email asking me to join the panel for the Devoxx closing speech. Why? Why me? None of these people had ever met me, I’d never presented at a conference before and I’m not exactly famous in the IT community. Apparently I offered a different perspective to the other speakers and they wanted the variety. I decided to go along with it so I agreed to come along to the opening dinner and meet some of the other presenters. I’m glad I did – it felt like my five minutes of fame! We were ushered through a restaurant past the mere public and into a huge back room where we were plied with champagne and attention and generally made to feel incredibly important. I spoke to some very nice people, not having a clue who any of them were, and having to manage awkward moments like being told, “You do realise that was THE Simon Brown?” Oh dear. None the wiser. I can’t have disgraced myself too badly though as I even got an offer to present at an American conference next year. I can see how this strange detached world of conference presenting can appeal, although the jet lag must be something else. Josh Long had hit 75,000 air miles in three months.
My presentation the next day went as well as I could have hoped. The room was fairly full – I hadn’t had that nightmare scenario of talking at the same time as someone really famous (or one of the robots) and although I think there was a slight tremor of nervousness in my voice I hope nobody noticed. The demos went smoothly, I did talk rather too fast and finish in 45 minutes but I don’t think anybody minded. I think the humour went okay – at least, I managed to get a groan and a head held in hands from the front row. The feedback afterwards was that my delivery was so deadpan that it took a while for people to realise that I was being funny! Might need to practice that one… I also got a lot of agreement, people pleased that I had “killed off SOAP” and sharing my opinions of EJBs, and generally positive comments and tweets throughout.
By the time the closing keynote came around I was much more relaxed and the panel-style staged interview questions flew by. I had to give a brief overview of my speech, and add in some agile client anecdotes whilst trying not to be star struck by the rest of the panel. Before I knew it, the beers were open and the credits were rolling and my five minutes of fame were up.
I went home that evening on a high, promising myself that I’d be back. Unfortunately however, this speech is the culmination of fifteen years of musings, I can’t just come up with something like that every day! Devoxx 2030 it is, then, I guess…
