Directionless Agile
I’ve seen some amazing things delivered via agile that could not possibly have been delivered in any other methodology. But it’s a wasteland. Here’s why.
Agile teaches developers that there are no rules, so long as they’re iterating on an idea and producing lots of “minimum viable product” drops along the way. Except viability isn’t being measured in 3 dimensions, it’s being measured purely in ostensible functionality. There’s no consideration for any direction or real capability. There’s no appreciation of any historical precedence or any future direction. It’s developing for now, to meet partially considered objectives, entirely on the basis that doing something quickly is better than any other paradigm.
Developer: “Hey, I’ve spun up a payments processing engine on a Commodore 64 I found on eBay — but the best bit is you perform the administration functions against it using a Minecraft control panel I built on my own Minecraft server which is running on two Raspberry Pi’s that are up in my bum running off bio energy converters. And it’s all written in BrainFuck.”
Agile Project Manager: “So, what I’m hearing is we have the ability to take payments? Great work everyone!”
The philosophy is based on the idea that smart people do smart things all the time. But that’s not always the case — I’d go so far as to say that’s not even often the case.
The first issue is the definition of ‘smart’, particularly as applied to a business.
Sure it’s smart of me to prove that the IOPS on MongoDB are substantially better than the IOPS on the current database tech that we use in the business. But what isn’t smart is deciding singlehandedly to go and put a production implementation of it on commodity, web-facing infrastructure, and then moving on to work on my next great idea.
Why? Well, first there’s the whole breach thing. And that’s sort of a biggie.
But beyond that, and even if there isn’t or wasn’t a breach, the idea that your tech-itch should be scratched on the business’s dime, that the existing stuff we’re paying for should sit there unused, that we now need to go out and pay for specialists to look after some new tech, and the idea that we’re going to still call this ‘smart’ and thank ourselves for our own brilliance?
Idiots.
And what’s the solution? Well, it’s architecture.
It’s not a new idea and it’s not necessarily going to be a popular one, but this problem has already been solved once. We figured out that for things to work best and most efficiently at any scale beyond “in my bedroom” we need a direction, an agreed way of doing things. We need to properly assess capabilities of technology, not just against how cool it is, but against how we’re going to run it, support it, and maintain it. We’re going to need to understand where it fits in the wider picture of technology and people and processes, and we’re going to need to understand that sometimes a slightly sub-optimal tech solution at the micro level brings with it more than sufficient compensation at the macro level. And yes, we need to plan for the future and move with the technology and adopt new paradigms, but we absolutely must not forget all of the history and work that went in to solving perennial problems that, whilst you may not currently be able to see, are definitely out there waiting for you.
Yes, Agile can be amazing. And yes, we should adopt it. But in doing so we shouldn’t be throwing out 50 years of accumulated experience at the same time.
And yes, how most people do architecture today sucks as well. But that’s a different rant for a different day.
