In January 2024, my comfortable tenure at Equal Experts came to an end and I went from 6 years of being a Java/Scala/AppSec consultant to being a head of engineering at a Middle Eastern fintech. This piece of writing explores what this means. I had been a tech lead before and certainly had plenty of experience of sitting at the table where decisions are made and have never had any qualms about sticking my beak in where it might not belong.

Have you ever struggled to find time for a workshop or a decent conversation? Because when you open your calendar it looks like this? Is it full of 1:1s Status Update Calls Readiness Calls Syncs Standups Project Updates Weekly meetings Biweekly meetings Sometimes it feels like “am I even doing any work”? I jest of course, because all these things are important. Without 1:1s we can’t build personal relationships, which helps us find the person behind a role.

This post is all about sustainablity. And communication. And agile. Let me start from the beginning. I’m sat on the train, coming back from Lean Agile Scotland 2024 and I’m thinking about what I’ve heard, seen and done. The conference was great, and allowed for catching up with old and new friends, finding kindred spirits and having good food. Yes, the older you get, the more important the question of “where shall we eat?

After the fantastic experience of speaking at Agile on the Beach 2023 a year before, I was back for more agile. This meant more driving: again I took the motorway barge for the long road trip from the North West to almost the tip of the South West. For international readers, when I say North West, I mean England, somewhere near Preston, and the South West is in pretty Falmouth, Kernow (Cornwall).

Once again, I’m sat at Schipol Airport typing up my thoughts about a few days of refreshing Dutch DevOps Goodness! Ok, I admit one or five alcoholic beverages might have been involved too. This was my first DevOpsDays and it did not disappoint. My day started at 3am to catch a flight at 6am but because I was still awake at 1:30 and had decided sleep is for wimps, I arrived a little bit wired.

Many conferences have a hallway track, I loved that Agile Manchester had a jigsaw track. The organisers put out a jigsaw on a big table where attendees could mingle over searching through the 2000 pieces and chat at the same time. Such a great way of breaking the ice. And such a brilliant metaphor. A complex task is achieved through self organisation. Teams self-select and offer assistance all without intervention and imposed coordination or management.

About two months ago I stumbled across a great YouTube video of a talk by Charity Majors called Compliance standards should be modern development practices. Now let’s step back for a minute. Am I seriously suggesting that anything with the word “compliance” is going to be a riveting watch? Why, yes I am. And with good reason. I’m a fan of good security and I like agile. And I think one of the major stumbling blocks about putting Sec into DevOps is to forget the agile origins of DevOps culture.

Last year was exciting, it was my first time going to a DevOps Enterprise Summit and meeting Gene Kim was very cool. The conference didn’t actually start on Tuesday, there was a little session on Monday as people were trickling in from all over the world. And in said session, Gene presented his latest project. He was writing a book with Steven Spears called Wiring the Winning Organisation. If I’m honest, I am not a fan of the title.

I describe myself as an Agile Fundamentalist because I really like the ideas of the Agile manifesto, and I also confidently state that I am an AppSec snooper, because in my day job I tend to look at other people’s code, logs and systems and break them. I happen to think that agile and application security go together rather well! I had two different Slack conversations recently. One was on the UK cross-governmental #security Slack channel and the other one was on the Equal Experts #securit-ee Slack channel (yes I’m a consultant, and our Slack channels have hilariously got ee in their names).

I am wearing my Equal Experts hoodie. Often I’ll be found on conference calls with my EE t-shirts, and I even have some socks. So the irony of writing an article about “leaving the badge on the door” is not lost on me. So what do I mean? Contracting Scum I am a contractor. I have been for the best part of 20 years. I’ve worked in a variety of sectors (telecomms, finance, government) in a variety of roles (development, architecture, security) using a variety of methodologies (waterfall - eurgh, faux agile - double eurgh - and lowercase agile).

I am back at home, a few days after my first experience of Agile on the Beach. There were a few problems with it (yes, yes, I’m baiting you, I loved it). There was too much quality, it was really hard to pick which talks to go to. There was too much fun, it was difficult to leave the after-party after the beach party. And it was hard to keep track of all the new faces and names.

As I am sitting at Schipol Airport, contemplating that the airport is so big it has a branch of the Rijksmuseum, I can’t help but thinking about the fabulous conference I’ve just been to. The DevOps Enterprise Summit 2023 has exceeded my expectations. But before I get to there, I’d just like to develop the airport metaphor a little bit. So here I am, looking at culture. Why was it that at Schipol, one of the busiest airports in the world, it was a breeze to get through security, airport security agents were smiling, cracking jokes, I could leave my laptop, toothpaste and deodorant in the bag and they have art in the middle of the airport, goddammit.

As I am sitting on the 16th floor of the Okura Hotel in Amsterdam in my Batman pyjamas and facing a large mirror, just glimpsing the paper crane that was so lovingly put on my pillow, I’m starting to reflect what has happened during the day. I was lucky enough to be a guest at the DevOps Enterprise Summit. There was certainly plenty of things to get excited about. I’d meet Gene Kim, who’s been running this conference for 10 years and who wrote the Phoenix Project.

“Outdated tech stack and metaphorical gaffer tape holding together the code” - sound familiar? How about “We can’t recruit, because nobody wants to touch this legacy stuff”? Yet banks and governments would stop working if mainframes were switched off. Instead of outsourcing to the lowest bidder, maintenance is a job for experienced engineers. Not “the short straw”, brown field development can be more exciting than a feature factory. After all, the shiny code written today is the legacy code of tomorrow…

Let me tell you a story about Application Security (AppSec). It contains heroes and villains, and I’m not necessarily thinking about the defenders and attackers here. It contains lots of interesting technology that is often overemphasised. We’ve got whole industries that work on letting us know how scary it is out there, vulnerabilities that are marketed like rock stars and terminology that makes you quiver in your boots: who would want to fall victim to an Advanced Persistent Threat (APT)?

I am sitting on the train as I type this coming back from my first IRL conference. Lean Agile Scotland 2022 was brilliant. I met so many people with ideas that just chime with my thinking on agile, I feel energised and full of ideas No Bugs No Decisions No Deadlines No Fear What follows are some thoughts that I took away from some of sessions the conference. There were lots of exciting talks and workshops and it was a pity that I couldn’t clone myself to go to more of them (I was gutted to miss sessions that coincided with my own talk).

This is part of my series of interview questions for Agile India 2022. Thinking about exciting developments in software development as a developer immediately brings magpies to mind. What is the latest technology that can grab our attention. What’s the latest shiny? Could it be some crypto tech? Some no-code development? Or programming in the metaverse maybe? No, no, and NO! Crypto is a scourge that wastes energy, kills the planet and destroys lives, no-code and low code will mean some actual software engineers will have to pick up the pieces when it inevitably will go wrong and the metaverse (second second life) looks to be a great way to make the web as tedious to use than going to an actual shop where you can’t find anything because the items have moved to another shelf yet again.

This is part of my series of interview questions for Agile India 2022. It is difficult to articulate what the biggest challenge to software product engineering is, because there’s a fair few of them, so I’ll try to describe a few of my bug bears. Process over people In my opinion, a huge issue that we unfortunately find all too often is when the principles of the agile manifesto are ignored or not applied.

After being accepted for speaking at Agile India 2022 I was asked a few questions. I figured rather than a paragraph, the questions would make interesting blog posts: I came to agile completely the wrong way. I’ve been developing software professionally since I was a teenager and was lucky enough to start out with projects where I was given plenty of agency to decide on how to tackle problems and the independence to make my own mistakes and learn from them.

Dave Farley and Allen Holub are two people that I respect hugely when it comes to Software Development. I’ve been following them on twitter for quite a while, and am always taken in about their takes on driving continuous delivery and “lowercase agile” forward. So when both came together for Dave’s Engineering Room (sponsored by Equal Experts, who I work with), it was bound to be very interesting. In this post I try to outline my key takeaways from watching the chat.

I was really positively and pleasantly surprised when I found out what HMRC Digital’s mission statement was. Normally, I am not a fan of mission statements. They usually read like this: Our mission is focused on six core aspirations the company continually strives to achieve… Or some such drivel. Verbal gymnastics to make a company sound like everything to everyone - without being offensive to anyone - which then gets used to “align” people on mandated fun days.

In this post, I am going to look at an increasingly important part of securing applications: Your supply chain. This includes every library, tool or service that you are using to build, run and monitor your service. When the log4shell vulnerability hit, it wasn’t just a matter of looking at the dependencies that your source code pulls in, but also at the infrastructure you’re using and the build pipeline. Have you had a look at the vulnerability reports of your dependencies lately?

This post peels back the covers on what it is like to work with a large digital platform. The platform in question is MDTP - Multichannel Digital Tax Platform, which supports a UK-based tax collection agency which is using a hyperscale cloud provider with a sideline in books. I’ve previously described what it is like to work in MDTP (Making Software. Quickly) during the Covid-19 responses that allowed the UK government to provide financial support for millions turning around projects in record time.

A few days back as part of a general discussion about interviewing at Equal Experts, we looked at the question “What makes a good developer?” Could we come up with a list of qualities in a developer that we’d want to look for? This post illustrates my thinking. Why do you ask? To put it in a bit of context, I’m a software developer, I’m not a recruiter, but I’ve been involved with technical interviewing for quite a while, and have marked a fair number of take-home tests over the years, but recently we thought that the experience was not as good as it could be.

Dave Farley and Martin Fowler are two heavyweights when it comes to Software Development. As well as his latest and hugely anticipated book Modern Software Engineering, Dave wrote Continuous Delivery. Martin co-wrote the Agile Manifesto and Refactoring. All of which are hugely influential to large swathes of software engineers. So when both came together for Dave’s new series on YouTube, the Engineering Room (sponsored by Equal Experts), it was bound to be very interesting.

Scenario: You’re in a handover session and explain everything in great detail but Dave is too hungover, Jim is on holiday and Jane is at another meeting and Chris isn’t asking any questions and in any case Trevor (who is actually going to be looking after this system after handover) hasn’t been recruited yet. Wouldn’t it be useful to record the session and make it available? Now, this piece of writing does not explore whether we should be recording meetings, nor does it attempt to answer the question of whether good documentation wouldn’t be preferable to having to sit and spend hours watching someone droning on about something that could be condensed into a five minute read of a blog post.

To successfully deliver software a developer needs a shield and a sword. A good product owner, delivery manager or alike that will shield the engineers from having to attend too many meetings, giving long-winded status updates and essentially allow them to get on with it. Shields go to all the meetings with the “business” and explain what can and cannot be done, without the engineer having to attend. A shield would also filter all the last-minute requirements or requests for gold plating without having to be dragged into endless meetings.

In this post, I describe my personal experience of being part of a software development team working with Equal Experts and HMRC during Covid-19. Under normal circumstances, we’re responsible for tax services such as Self Assessment, PAYE Expenses and Benefits, VAT submissions amongst others. These services run on the Multi-channel Digital Tax Platform (MDTP). This platform is hosted in a hyperscale cloud (the cloud provider has a sideline selling books), run in-house by HMRC teams made up of permanent staff and consultants.