Originally posted as a Twitter thread.

I’ve been thinking a lot about serverless architecture and I’ve realised what bugs me about it.

This is gonna be a long one. Not gonna lie, I wrote a draft first. If I hadn’t, this thread would end right before it got interesting because I’d get distracted by a butterfly.

At its heart, serverless/FaaS/lambda/whatever-you-call-it works for me because it ties action to cost. The more I do (or the more inefficiently I do it), the more I pay. More users, more money. Gojko Adzic wrote about this years ago. It’s not new.

The problem, I find, is that in doing so, it breaks your application apart. Now we have many applications. They all work with HTTP, or message queues, or some other data interchange layer I don’t care about when I’m designing functionality for a user.

I was listening to Ron Jeffries and Chet Hendrickson on the Cucumber podcast, and I heard something that helped me reframe agility and craft in a way that was very meaningful to me.

He was prompted by Sal Freudenberg talking about asking for permission to use techniques such as test-driven development, rather than treating it as part of the job.

Chet Hendrickson: I think you’re right; it seems odd that we ask permission. We believe we have to have permission to do good work. I believe that on the first day of a new greenfield project, the codebase is perfect. It does exactly nothing, and it does it in zero lines of code.

On Friday, I gave a talk at the Joy of Coding conference. The topic: “Teaching a Machine to Code”.

In this talk, I explained why we at Prodo.AI are working on next-generation tooling for developers, leveraging neural networks alongside traditional static analysis to find problems faster.

I also gave four (live!) demonstrations of how we can use machine learning and other more “human” techniques to detect and repair defects in code.

But mostly I talked about the difference between humans and machines, and how we can rebalance software development in favour of creativity.