“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…

The question of automatic dependency updates came up in our Slack channel the other day. There was a lot of nodding on how it is a good thing. Tools like Dependabot and Renovate were mentioned. Yet I was a dissenting voice. Why? The case for automatic dependency updates is simple and seductive: A bot would automatically scan your dependencies in your source code and create pull requests to update your libraries to the latest versions, sometimes even automatically merging it in.

From a security point of view, application logs are two-sided. On the one hand, it is really important to have good observability, to find out what is happening and what has happened. On the other hand, we don’t want to leak sensitive information. In this post I am going to look at the kinds of things you might find in your logs. The juicy bits are Personal Identifying Information (PII) or security credentials.

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)?

There’s a metaphor about the fight between attackers and defenders in the Denial of Service cybersecurity game. It’s an “arms race” between ever bigger attacks throwing huge amounts of traffic at ever more sophisticated defenses (e.g. AWS shield). Incidentally, I’ve just demonstrated an easy mistake: I’m not describing a Denial of Service (DoS) attack, it’s a Distributed Denial of Service (DDoS) attack. The aim is to overwhelm the infrastructure, either the networking infrastructure or the application by sending more requests than can be handled.

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.