Most of these practices come from my experience, working at scale with real teams and real systems, or from discussions with others in a similar situation. They also draw on decades of software and infrastructure best practices that apply just as well to agentic development as they did before AI existed.

The key assumption I’ve used for many years is this:

Constraints accelerate teams

Removing decisions from developers, which in this context includes AI agents, reduces cognitive load for people, and context for AI agents, and increases velocity. If that assumption does not fit your context, these practices may not fit either.

Each practice stands on its own. You do not have to adopt all of them at once. Start with one, see the value, and build from there. But the more of them you adopt, the more they reinforce each other and the more likely I think it is that you will see long term value.

1. No governance, no agent

If you follow this practice: you never have to wonder whether the agent was operating under rules or not. That question is answered structurally.

If governance is unavailable, the agent must not start. This is not a configuration option. It is the most fundamental principle in this document. An agent operating without governance is an agent operating without constraints, and an agent without constraints is ungoverned risk.

This applies regardless of context: a solo developer whose governance file is missing, a worker agent whose MCP server is unreachable, or a swarm whose orchestrator failed to pass a governance anchor. In every case the correct behaviour is the same. No governance, no session. Default-deny on unavailability is non-negotiable.

2. Governance must have a single canonical source that every agent can prove it used

If you follow this practice: you never have to reconcile what the agent was told against what the rules say. They are always the same thing.

Governance must live in an authoritative, version-controlled location. For simple setups that is a file at the repo root. For orchestrated or multi-repo environments it may be an external store such as a governance server or MCP server, with a hook that pulls the current governance into each agent’s context before the session starts. Either way, the governance version or hash that was active at the time of each run must be recorded alongside the work, so any session can be audited against the exact rules that applied to it.

Every project needs an explicit, committed contract between the team and the agent. Without it, each developer or agent is running under subtly different assumptions. That divergence compounds silently and surfaces at the worst moments.

3. Agent context comes from governance.

If you follow this practice: you never have to decide in the moment how much to trust the agent’s context. The rules decide for you.

Any prompt, instruction file, or context document given to the agent should reference the governance definition as its source of truth. Editing the agent context directly is the same as editing a build artefact: it will drift from the rules it is supposed to reflect. Governance derived from agent context is never valid.

This separation keeps machine-readable rules and human-readable context in sync. It also makes it obvious where a rule change should happen: in the governance definition, through a gated review, not in a file that an agent might have helped write.

4. Give the agent the minimum autonomy required

If you follow this practice: you never have to decide in the moment how much autonomy to grant the agent. The rules decide for you.

Guardrails are not bureaucracy. They are least-privilege permissions applied to an agent. A pause for human confirmation costs a developer thirty seconds. An unchecked agent adding a new external dependency costs the team hours of review, security assessment, and potential incident recovery. Granting maximum available autonomy by default is not a shortcut; it is deferred risk.

Not all decisions carry equal consequence. Adding a log statement is reversible in minutes. Adding a dependency, changing an interface, or touching a deployment pipeline can affect the entire team and beyond. Governance should reflect that difference explicitly: some actions the agent can take freely, others require a human in the loop before proceeding.

5. Every rule needs a reason, not just a constraint

If you follow this practice: you never have to explain a rule twice because the reason is already there.

A rule without a reason is a rule that gets bypassed the moment it causes friction. The intent behind each constraint is not optional. It is the load-bearing element that makes the system durable over time and across team members.

Developers who understand why a constraint exists will apply it correctly in novel situations. Developers who only know what the constraint is will route around it the first time it feels inconvenient. This applies equally to human developers and AI agents.

6. Compliance is always a human responsibility

If you follow this practice: you always know where to look when something goes wrong. Compliance has defined checkpoints, not open-ended questions.

The agent is a participant in a governed system, not a regulator of it.

Compliance is never the agent’s responsibility.

The agent follows governance when governance is present in its context. It does not enforce governance on itself, audit its own actions, or remember constraints across sessions. In long sessions, governance injected at the start competes with an expanding context window: as context grows, the agent’s effective adherence to early instructions degrades. This is a property of how these models work, not a failure of governance design.

Assuming the agent remains fully governed throughout a long session is the most dangerous mistake a team can make.

In a single-developer or small-team context, compliance is discharged across three points: session setup (governance must be explicitly present in the agent’s context, verified per tooling), change review (reviewers check governance compliance, not just code correctness), and evidence audit (regular review of agent interactions surfaces drift between what the rules say and what the agent is actually doing).

At orchestration scale, where dozens of agents may be running concurrently, real-time human supervision of individual agents is not possible.

Compliance responsibility does not disappear; it shifts to audit. The human’s job becomes: ensure the evidence exists, define what compliance looks like in advance, and review the evidence at a regular cadence. If those three things are true, compliance remains a human responsibility regardless of how many agents are running. The question is never “did a human watch every agent?” It is “can a human determine, after the fact, whether governance was followed?”

7. One intent per session

If you follow this practice: you never have to reconstruct what the agent was trying to do. It was declared before the session started.

Each agent session should have a single stated goal, scoped to the current working context. An agent with a vague or broad mandate will make broader decisions. An agent told “fix the text extraction bug in parser.js” has a narrowly bounded scope of action.

Unbounded sessions produce unbounded side effects. Scope is not a limitation on the agent’s capability; it is the mechanism by which the human retains meaningful oversight.

8. Short sessions are better than long ones

If you follow this practice: governance degradation within a session becomes a managed risk rather than a silent one.

The longer a session runs, the more context accumulates, and the more governance injected at the start is diluted. This is not a bug. It is how large language models work. A short session with a single declared intent completes before governance has a chance to degrade. A long, open-ended session drifts. Keeping sessions short is the simplest available control against within-session governance degradation. When sessions must be longer, governance should be re-confirmed at regular intervals and every response should be identifiable against the governance version it was operating under. Periodic re-confirmation mitigates what short sessions prevent.

9. Governance changes always require human approval

If you follow this practice: you never have to ask who changed the rules, when, or why. The record is in the change history.

A rule relaxation is a higher-risk change than most feature additions. The more consequential the rule being changed, the more scrutiny the review should attract. Changes that expand what the agent can do autonomously should require a named governance owner to approve, with a record of who proposed the change, why, and who approved it. In a git-based workflow, a pull request is the natural gate, just like any other code change.

Treating governance as a living document is healthy.

Treating governance as something that can be edited casually mid-session is not.

The friction of requiring human approval is the point.

10. Passing tests confirm correctness, not governance compliance

If you follow this practice: you never mistake a green build for a governed build. They are different things with different checks.

Passing tests confirm the agent did not break existing behaviour. They do not confirm the agent stayed within its architectural constraints.

A function that passes all tests but introduces a new external dependency may have violated governance even though CI is green.

Both signals are necessary. Neither replaces the other. Governance compliance is checked by humans as part of the change review process, not by the test suite.

11. Onboarding starts with intent, not rules

If you follow this practice: onboarding a new developer or a new agent takes minutes, not days. The reasoning is already written down.

A new team member who reads only the governance rules will treat them as a checklist. A new team member who reads the intent behind each constraint will understand why they exist and will apply them correctly to situations the rules did not anticipate.

Intent should be written to a consistent template for example:

“[subject] needs [constraint] because [consequence of not having it].”

If the “because” cannot be completed, the rule is not ready to be committed. A rule you cannot explain is a rule that will be bypassed or deleted under pressure.

For example:

“The project needs all external dependencies explicitly approved because every unreviewed library is a future security and maintenance liability.”

That single sentence tells a new developer, and the agent, not just what the rule is but what reasoning to apply when they encounter a situation the rule did not anticipate.

Onboarding to a governed project should begin with the governance definition, not the codebase. The constraints are the architecture. Understanding them is the prerequisite for contributing safely.

12. No evidence, no accountability

If you follow this practice: governance improvement is a structured activity with evidence, not an opinion-driven debate about what the agent should or should not be allowed to do.

When an agent takes a destructive or unexpected action (PocketOS is a very useful cautionary tale) and there is no transcript, the only record of what happened is the agent’s own explanation of what it did and why. That is not accountability. Without retained evidence, there is no basis for audit, no basis for governance improvement, and no basis for trust.

That evidence must be retained: stored, attributable to a developer or agent and session, and kept for at least the current review cycle. Every AI tooling choice made by the team should be evaluated partly on whether it supports evidence retention.

For a single developer or small team, evidence is the session transcript. At orchestration scale, structured telemetry (event logs, metrics, escalation records) is more tractable: machine-readable, queryable, and aggregable across many agents simultaneously.

Whatever approach is needed, the principle is the same. At a regular cadence (a sprint is a reasonable default), accumulated evidence should be reviewed to surface patterns: rules that were escalated frequently, rules that were never triggered, and agent behaviours that no current rule addresses.

AI tooling can assist with this review pass, but the output must be proposals only. Suggested governance changes must go through the same human approval process as any other rule change.

The agent does not update its own constraints.

Humans do, on the basis of evidence.

13. The AI does not own governance. You do

If you follow this practice: there is no ambiguity about who is accountable when something goes wrong. The AI assisted. You decided.

In a constrained, agent-assisted team, the human’s primary leverage is the quality and integrity of the governance model. Approving rule changes, monitoring escalation patterns, and ensuring intent stays current as the project evolves are first-class responsibilities.

Delivery is governed by the rules you set. If the governance is wrong, the delivery will be wrong and your risks will increase. Ownership of one is ownership of both.

Velocity comes from the constraints. Protecting the constraints is how the team, including the AI agents, protects its ability to move fast. A governance model that drifts becomes noise, and noise gets ignored.

Conclusion

There are many possible best practices for agentic development and this is my view on what the important ones are for using LLMs in software development.

This set of practices deliberately focuses on governance, and attempts to avoid repeating the areas of software delivery and practice where we have 50+ years of experience and guidance. Those practices still apply and are not replaced by any of this.

These best practices are part of a wider set of practices I use whenever I am acting as a CTO or adviser. I’ve written best practices before including the serverless best practices I wrote in 2018 for use with (primarily) AWS serverless solutions.

Looking forward to hearing what you think and what I have missed. As with all tools, knowing how best to use LLMs and where they have limitations is critical to using them well.

And most people I know in tech would do something else, if the money was better.

Most people seem to hate their job in some way. Not the people, but the job, the pressure, the stress, and the constant nature of that stress.

I’ve been involved at senior and leadership level in developing or supporting the development of many many applications for companies and organisations ranging from the very small to very large including for Governments and some of the largest orgs in the world.

I’ve been doing this at this level for around 2 decades.

I’ve learned a huge amount about what should be done and what should not be done. If there’s one thing I can tell you, it is that I will change my mind again about what I write here at some point in the future, because tech does not stand still.

Maybe there’s a way to put some principles in place that can improve how we do tech that benefits the people that work in it, and still delivers the necessary solutions.

Here are some principles, or guidelines maybe, that I think can help do this:

Principle: Know what the need is

This may seem to be obvious, but it’s not.

The idea of “customer need” or similar is in pretty much every project/product management mantra/framework/practice I can think of.

But there is a difference between thinking you understand your customer‘s needs and actually knowing that the customer has that need.

It’s much much harder to know.

“What the need is” is almost always ignored, or considered to be “clear and unambiguous”, until well after development of any solution has started.

Very few people in tech actually do this properly.

Everybody says they do this, but what most people actually do is guess, or assume the need from their own bias, or from minimal interaction with very few customers.

Identifying needs properly takes a huge amount of effort. Much more than most companies put in, and often the effort put in is expended in an attempt to confirm the bias that already exists.

Building the wrong thing can be very demoralising. Start here if you want to make people who work for you happy.

If you cannot clearly identify a customer need, then you cannot define the solution that you need to create to meet that need, and you shouldn’t start anything until you do.

Principle: Meet the need as simply as possible

You wouldn’t believe how obvious this is either, and how often this is either missed, or what happens more often, the solution that is created is far more complex than the need is, and can create additional needs that were not there to start with.

An example is useful here:

At one of my previous startups, the marketing team were struggling to get the right data out of our analytics. So I sat down with the Head of Marketing (one of the other 4 people in the startup) and worked out exactly what they needed. They needed CSV files corresponding to a specific set of queries of the data. They needed these CSV files every morning and they needed to correspond to the previous midnight to midnight (UTC+0) timespan. In previous startups, I would likely have provided them with a simple web interface, with a username and password and everything else that goes with it (which would have been relatively easy to do but a pain to maintain). However, we were already using slack, so I created an AWS Lambda function to generate the previous 24 hours data on a schedule during the early hours, and saved the data into S3. I then sent the data in S3 in a slack message to a slack channel only available to the Head of Marketing and myself. He then downloaded it every morning into Excel. This was our marketing process for extracting data from analytics for 18 months with only minor tweaks to the queries needed over that time. The Head of Marketing was ecstatic because it was immediately available to him every morning and he could do whatever he wanted via Excel without worrying about deleting data on a shared drive or similar because it was saved and in S3. It could also be recreated without issue if needed.

This is an example of meeting the need, and only the need.

Maintaining that solution was very straight forward. The amount of code was limited and there was no running server. The Head of Marketing could get his data every day and could even leave it a few days if needed because the data didn’t get deleted (until archived months later). The solution lasted 18 months because we figured out the specific need before doing any delivery work.

If I’d provided a web interface, I would have been on the hook for managing and supporting a web interface, including the underlying server (or serverless implementation) and the security implications that authentication and authorization on a web server requires for that kind of solution. None of that was required.

People like to build simple things. It’s usually quicker and easier, and the response is often more joyful.

Win-win.

Understand and meet the need and only the need.

Principle: Build to maintain because maintenance is far far more painful than initial build

Most tech people, when they look at a new project, will consider how long the initial build will take. This is generally based on experience of how much coding is involved, how good they and the team around them are, and how complex the logic of the application is.

What almost nobody is good at is understanding the level of maintenance required for the solution once built.

One of the biggest frustrations that I have when talking to people who have worked in tech for a long time is that they believe that the “maintenance“ aspect of a solution is almost a “tax” on a project. It’s just something that has to be paid, and there is no way of minimising that tax.

In other words, if you build any solution and it has X lines of code, then you’re going to need Y humans and Z days per month simply on maintaining that solution.

The idea that maintenance is “baked in” seems to also get worse among people who are advocates of “never-non-open-source” (those people who constantly say that open source solutions are the best and the only ones people should ever use).

Reducing maintenance time is a fundamental good in every single project, and if you can prove that increasing the amount of initial build time is very likely to achieve a reduction in maintenance then longer builds are a reasonable price to pay.

Let me explain:

(These graphs are idealised and not based on real data so don’t come at me, and are intended to help explain the point)

The area under the graph is Total Effort.

It’s pretty obvious to me which one is better over time.

I am not saying that maintenance is never needed, or that maintenance will not increase over time as an application gets older (as that almost always happens).

This is a big part of the “why” of serverless

The point is that considering maintenance in the design right at the start can make a huge difference to the amount of effort required over the entire project.

This is a major reason why I advocate for a serverless approach, because the maintenance involved in a well designed application is so much lower.

Note: the “serverless approach” in the above scenario does not advocate for the use of container-based solutions because those require significantly more maintenance than avoiding all container- and instance-based solutions. I am not against containers, but I am advocating against them because they are harder to maintain over the long term than, for example, zip files in AWS Lambda functions.

“… but you’re wrong”

Focusing on maintenance will mean that some decisions seem “wrong” to experienced tech people.

I have been told on many occasions that my approach is wrong or something that people “aren’t used to” so will take “longer”. I’ve had to stand my ground on multiple occasions to get this across to people.

I am very willing to accept that I don’t know everything, but I am not going to accept that people can’t do things because they aren’t used to them.

People can learn things, and adapt. There is nothing that says that the way we used to do it in the tech industry is always “right”.

However…

One of my worst experiences in tech was when a senior leader who was supposed to be following the guidelines and principles I had created for the org as an expert consultant, simply refused to accept that I had any understanding or experience of how to build large scale solutions.

He totally undermined my approach to the team that he led, which was one of several that were supposed to be integrating their solutions over time. It led to his being nice to my face and in meetings, and behind my back their team completely ignored my advice, did their own thing, and ended up with a solution that did not integrate or work well with the multiple other aspects of the solution being built. He blamed me for this.

What ended up happening was that all the other teams ended up taking a few weeks longer on the initial build, but ended up being able to fix bugs and maintain their solutions much more easily than this other team. They completed their solutions approximately on time. The launch of the application was however delayed because of only one team, and I couldn’t help them very much because the team leader had ignored my advice and his team had been poisoned against me.

It might seem obvious, but one of the big things about maintenance is that the person that builds something is almost certainly not going to be the one that maintains it in the distant future.

Whatever you create, make it so that it is easy to maintain. Don’t allow a deadline to drag your focus from this (unless it is absolute).

Principle: Use the shortcuts Luke!

Your solution is about how to meet the Need you have identified.

Your solution is not about how clever you are as a programmer.

Your solution should not be about ensuring that you keep your job by making it impossible for others to understand what you have built…

…although I also suggest that it is also a good idea to not intentionally do yourself out of a job by running out of work!

Let me assure you that I’ve only ever worked in one place where we kept running out of work to do, and that’s because I was the CTO, and I was following these principles (although they weren’t laid out like this). At that point, we could start experimenting with new ideas and features, because maintenance was easy, and that was when work was fun.

So what do I mean by shortcuts?

Do not build things yourself that other people have built and are cost-effective to use.

The majority of solutions that have a web interface use an open source backend solution running on the cloud in some form.

With the rise of “serverless” solutions (I’m using the quotes intentionally) there has been a rise in limiting the use of instances and servers.

However for most of the bigger orgs, the solutions that they create tend to be running in kubernetes, and use something like python or node.js to create the web application to run on it.

Then there is the necessity to write the web application, use a data store of some sort which is very often but not always an RDBMS in the cloud, and then deploy the kubernetes cluster to a cloud provider.

Some see this as “serverless” especially if they use very small container runtimes which is possible to do. I don’t, because you’re still needing to maintain that container which significant effort.

The reason I find this baffling is because the maintenance involved in this is enormous in comparison to what I do.

My approach is to use the shortcuts available from the cloud providers.

All the kubernetes solution does is to provide compartmentalised compute. You still have to define what goes in each compartment, and even if you get the cloud provider to run the kubernetes cluster (so you don’t have to) it’s a lot of effort to achieve this.

Why not just bypass this whole issue?

Why not just… give the cloud provider the code, and let them figure out the rest?

Taking AWS as an example (it’s what I know best):

• API Gateway for HTTP layer
• AWS Lambda (zip files only) for compute layer
• AWS Lambda functions are one function per route for HTTP layer
• AWS Lambda development focus is on minimising cold starts*
• No instances or containers
• Long running tasks (longer than AWS Lambda timeouts) are broken down into steps and either use Step Functions or custom process (as these would never use a request-response architecture)
• Use DynamoDB for small and rapid data storage and retrieval elements
• Use S3 for blob/file storage and retrieval
• Use an authn/authz solution e.g. Cognito or similar
• Manage all the above via CloudFormation solution such as SAM or CDK

*Note: Don’t start with java!!! Minimising cold starts comes under the “reducing maintenance“ principle. This is because cold starts are much harder to reduce once the code has been created and deployed. It’s also why I always tell companies to avoid java as the first choice of language for Lambda functions. It is possible to build really good Lambda functions in java if you are experienced but most are not to begin with and end up with very bad cold start performance even with all the new stuff that AWS has produced.

These are all shortcuts to avoid having to build elements of a solution that are not core to the business and therefore the solution.

It has not been “core” to any business for a very long time to “build” an HTTP layer or a “container”.

Knowing how to build these solutions is not easy if you haven’t done it before, but essentially the design of the solution partially moves from the “framework” to the “infrastructure as code”. They are far more intertwined.

Which means that you cannot separate out your Dev and your Ops teams in the same way.

It also means that you cannot run everything “locally” because there is simply no point in trying to replicate “the cloud” on a local machine. Better to actually develop in the cloud, and create tests for the much smaller amounts of code that you create, before deployment.

It’s much easier.

Because you’re using the cloud to shortcut your way to a solution, shorten the build time, and reduce maintenance.

If you are very good at working with shortcuts you can create a solutions much more quickly, and make solutions more maintainable and extensible.

This takes practice, but once you have seen it, you can’t unsee it.

Principle: Understand how the solution can be retired and/or replaced

This is one thing I don’t think anyone in tech is very good at, including me.

It is however one thing I am increasingly aware of.

One of the reasons I think that people who do not understand technology struggle to understand the costs of technology is because, as an industry we are very bad at knowing when to replace a solution.

The techies on the front line will be spending a lot of time fixing issues with a solution that the company says is critical to their business, and the team will keep working on it faithfully.

But very few people will think “is this the right approach?” or “should we be building a replacement which is easier to maintain?”.

Our understanding of risk and the costs of delivering the solution and how we understand maintenance are all linked to this.

If we see maintenance as “just another tech tax” then there really isn’t much point in building another version of a solution, because the team will just have to maintain that new thing.

That’s pointless.

But if the new solution is easier to maintain, because it was built to be maintained more easily, then the conversation changes and the risk changes.

Add to that, that if the need is well understood, and the solution is reaching a recognised threshold of maintenance (“beyond this point/amount of effort expended per month we need to consider replacing this solution with a new one”), then it becomes a lot easier to discuss building a replacement much earlier, and costing in the effort of delivery.

The majority of solutions that I see are maintained until the solution effectively becomes virtually impossible to maintain or impossible to replace… or both.

When that happens, the cost of maintenance or replacement becomes so high, that the business suffers.

If you as a team or org can identify a way of having a regular conversation around whether a solution is worth maintaining for another period or whether the investment in a new solution is the right approach, then so long as the need is front and centre of that conversation, who built the solution and whether they are doing a “good” or a “bad” job is secondary.

A team with the best intentions cannot maintain a solution forever, whatever that solution is.

People don’t like doing a bad job. Doing maintenance is painful if the solution is difficult to maintain.

Identifying when to replace a solution should be regularly considered and should have some accompanying metrics.

Principle: Teams are people not resources

There are going to be times when deadlines need to be hit in every organisation.

But the fact is, that we’ve created a system for the tech teams in our organisations where non-critical and totally artificial deadlines are setup for them almost daily.

And they are setup to constantly fail.

The other aspect is that we have normalised this behaviour to the point that senior leaders expect the deadlines provided to be hard and fast, and not guidelines, because they can see the dates and times in the online management solutions.

In tech, we don’t price in breaks, or days when the tech just doesn’t work, or sickness, or anything like that any more.

And when we push people to hit deadlines, we definitely don’t make them consider whether the solution they are creating is maintainable.

Essentially we push people to create things that are “somebody else’s problem”.

We also don’t give anyone space and time to learn anything.

And don’t give me the “innovation tokens” idea because of “limited capacity”. This isn’t the right way to think about people. If there is limited capacity because the deadlines are racing at people, then someone, somewhere didn’t give people the right amount of time to learn something new, or the right amount of time to deliver the project.

I would never have built serverless things unless I had been in total charge of my timescales and how I delivered things.

We learn by making mistakes and then not being yelled at or penalised for doing so.

Your people will never give their best if you don’t give them space to learn.

They will not be able to build great solutions, and help their future selves and future colleagues out by considering maintenance if they are constantly under pressure.

I hate the idea of “post mortems” because NOBODY DIED. We’re not dissecting remains of something dead. Maybe call it something else?

The culture of technology is so bad, in so many ways, that it’s no wonder that people that come into tech are enthused for a short period, and then become disillusioned with it.

I had a principle as a startup CTO which was that my team only needed to do 6 good hours in a day, and it was up to them when they finished.

It was informal and not a “hard and fast rule”, but it was important. If someone felt they’d done good work, and wanted to go home early, then they absolutely could.

That startup produced some of the most effective and efficient people I’ve ever worked with in tech. It wasn’t perfect, because nothing ever is, but I like to think that people were happy there.

I’d far rather have that, than a lot of people stressed about hitting a deadline. It was a better attitude than most companies I’ve worked in (I may be delusional here too!) and the team was not put under pressure by me. We still delivered what we needed and often well before it was needed.

One thing that is worth saying is that sometimes people need to leave, and sometimes people need to be fired. There is nothing that says you need to be vindictive or mean when somebody leaves.

Sometimes also a company or organisation isn’t right for me. Mental health is important too and I’ve left a number of roles because of my mental health.

The tech industry has a lot to learn here.

Look after people, and they will look after you and the company. It’s not a family, it’s a job, so treat people with respect.

Conclusion

This wasn’t the post I set out to write.

But this is what came out.

When I work with tech teams and companies, the biggest thing is that it is often really difficult to identify and understand how a company and a team should work on a high level.

There are lots of approaches and strategies e.g. Agile. Most of the approaches seem to get reduced to a set of 1s and 0s by a tech company somewhere and make the humans that have to deliver within the approach much less happy than they could be.

What I’ve tried to put into words is how I want to work with people, and some of the principles I give to people when I am working on a project.

The role I take sometimes is as a non-exec director or maybe I’m a fractional CTO or maybe I’m just advising, but whatever the role, these are the kinds of things I end up saying in one form or another over and over again.

And the biggest problem is that I end up fighting against the tech industry.

The tech industry thinks that it has a lot of the answers.

But so often the tech industry answers to these problems end up being very hard on the people who end up doing the work, the techies themselves.

And the problem there is that the techies seem to think that anything that looks different is “wrong”.

In the end, what I think I most care about is whether people are able to do their jobs without being bullied or feeling undue pressure and affecting their mental health.

I’ve been in too many places in tech where mental health and pressure are secondary (and sometimes much further back than that) to delivery.

People that work in the industry don’t hate people, but the industry overall is enabled by all of us. There are many lovely people in the industry, but it’s far too often “copy and paste” practices from one org to another that mean that we don’t learn and continue to propagate bad practices.

We need to push back on the practices in the tech industry that make many people unhappy because they will invariably do a better job when they are happy.

The tech industry is really not a great place to work for many many people.

In my own small way, I’m trying to change that.

Maybe you should too.

The original post is here:

Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% — Prime Video Tech

I very much agree with Adrian Cockcroft and his post So many bad takes — What is there to learn from the Prime Video microservices to monolith story.

Words matter

What the Prime Video team did was quite simple: they built a “serverless first” initial version, and then modified it to use containers when they needed to optimise elements of the system. With more experience, they could have built a better system initially, but that’s what learning is about.

The improved version is still serverless in my view.

It’s not a monolith.

The idea that serverless systems must only contain Lambda functions for compute is wrong or always use specific technologies and never use others is wrong.

These words and concepts are so badly defined for most people in tech and most people never interrogate their own bias.

Just as we rarely consider the words “microservices” and “server” and “data centre” and “instance” and “container”.

The root of why this Prime Video tech post became such a lightning rod was simply that the original post was badly written, and the terminology used confused so many terms, that it made it impossible unless you read the whole thing and understand what serverless is to understand what they are trying to say.

Or, the short version: it’s a really badly written blog post.

What the Prime Video team actually did

In effect, all the team did was to replace a Step Functions workload with an ECS workload and for very good technical reasons.

In essence it is the same system if you look at it as a black box, because the SNS topic and S3 bucket are the outputs for both, and the inputs are events from the customer.

Calling this a “monolith” is not right in my view. It’s event driven, it’s triggered via a lambda function, it’s scaling using ECS rather than Step Functions, and crucially there is something else that they realised that makes the ECS version better.

The ECS version is better than the Step Functions version because the task that they were attempting to do — analysing video streams — didn’t work so well within Step Functions, but worked a lot better when the task was run on a single container.

This makes sense, and is explained well in the article. Passing lots of data around a distributed system is slower and more expensive than keeping it in a container and orchestrating it in the container. That’s obvious if you think about it as well.

Now, Prime Video also hit scaling limits. Not everyone has Prime Video’s problems. Most people don’t. It’s one of the reasons you would look at moving certain workloads of very high load distributed compute away from AWS Lambda.

Side Note: I am going to stress very strongly at this point that very few workloads when well designed actually reach the point of hitting scaling limits with serverless, so scaling limits are almost never a reason to dismiss AWS Lambda or serverless at the design stage. I have never found it an issue with any of the solutions I’ve designed.

If you need to move compute away from AWS Lambda, you move it to autoscaling ECS tasks triggered by AWS Lambda. This is pretty much still serverless, but instead of pay-per-use compute, you are recognising that your workload is likely never going to scale to zero (which is a useful thing to know), so at that point you can optimise for the scale you have by using containers.

It’s still serverless.

It’s a very good example of refining a serverless solution in my view.

But the Prime Video blog post is still really badly written

What went wrong?

The penultimate part of the post is called “From distributed microservices to a monolith application”.

The final section is called “Results and Takeaways”

“Serverless” is used three times in the blog post. Twice as “serverless components” and once as “serverless architecture”. There is a lot of discussion in the post about a “distributed” approach, separately from the word “serverless”.

Then there are the uses of the words “microservices”, “services” and “distributed systems”.

They talk about their initial solution being a “distributed system using serverless components”, they then “migrated to a monolith”, but then said that “Conceptually, the high-level architecture remained the same”.

And then, they “cloned the service multiple times” (“service” here refers to the container based solution they had built to replace the Step Functions based part of the solution) and then built a higher level orchestration layer to distribute requests.

In other words, they built something that looks a lot like… Step Functions.

It’s all about the words

I hope that you can see that the blog post is incredibly confusing from a terminology point of view.

What is a “serverless component”?

What is a “distributed component”?

What is a “service” or “microservice”?

For that matter what is a “distributed system” as opposed to a “serverless architecture”?

You might think I’m nitpicking.

I am definitely nitpicking.

Why?

If you’ve not come across me before, I used to be the Senior Developer Advocate for Serverless at AWS from 2017–18. I wrote some blog posts in that time. We had rules we had to follow, and the blog posts had to pass some quite serious review procedures (they were called “Chris Munns”).

This blog wouldn’t have got past first review and would have been politely sent back with many revisions or more likely “please review the policies and rewrite”.

This blog post has a mish mash of ill defined terms and it’s unclear what the purpose of the article is.

Do you know what the purpose of the article is? If the purpose was to explain how to modify a serverless architecture when you hit scale limits, which is what it should have been about, then the article failed spectacularly.

And worst of all, it can easily be used to be critical of AWS, AWS Lambda, serverless, and also undermine the very hard work of another part of Amazon.

And it has done significant damage to the work of the serverless community.

This blog post has been thrown at me from multiple people saying “what do you think of that?” and telling me that even Amazon don’t think “serverless” can do “scale”.

It’s just more ammunition for people who don’t know what they’re talking about to dismiss “serverless” as an option.

It sucks because those of us who have been doing serverless incredibly successfully for years have had to put up with FUD like this from uninformed people for so long. For this blog post to have delivered this kind of destructive ammunition to the tech world from an AMAZON company is just an absolute nightmare.

Prime Video is part of Amazon, but it’s not part of AWS. For some reason many people think that “Amazon” is a single entity and that it’s a big office somewhere in a building in Seattle. I know it’s hard to understand but it’s not that hard. And when people see Amazon, they think that it carries the weight of AWS as well. That’s why it matters.

I don’t think that the blog is under the purview of AWS (pretty sure it’s not) and so AWS likely don’t have editorial control. But I suspect that there has been a very strongly worded statement from AWS to all areas of Amazon that will essentially say “don’t you dare do something like this again”.

It’s probably hoping that the tech world ignore it, but the fact is that it keeps getting brought up to me.

Why write this blog?

I’m going to point people to this blog post as my response if anyone else asks me about that post or the D and H and H one.

I’ve already got annoyed in other social media forums, but that rarely stays visible.

While I do agree with Adrian, the thing that annoys me about this whole thing is how this all could have been avoided.

When you work at a company like Amazon, your words have consequences. It is one of the reasons that I actually ended up not liking it working there. I knew how important the words I wrote and said were, and it caused me stress and anxiety. (I know now this was partly as a result of having undiagnosed ADHD)

That Prime Video blog post feels like someone doesn’t understand how powerful words can be when your words are linked to a company like Amazon. It also feels like someone didn’t understand how the words would hit in other communities.

It is very hard to write really good content in tech.

This should be a case study in how not to do it.

Because some of us have worked very hard to get it right.

One of the biggest hurdles for pretty much all people with Wardley Maps is that the finished map looks really clear, but actually making a map can be really challenging. Often this step is what puts people off even trying to make a Wardley Map. I was certainly intimidated by what I thought was needed, and it put me off trying for several years.

4 simple rules for simple Wardley maps

On a Wardley Map:

1. vertical (see [2]) and horizontal (see [4]) position have meaning, but it is only relative to other elements of the Map
2. “needs” relationship are modelled vertically upwards
3. “anchors” are “components” that have no needs
4. each “component” on a Wardley Map needs to have an evolution “score” relative to all other “components” on the same map and this is modelled horizontally increasing (“more evolved”) to the right

There are a few things to explain here, so let’s quickly do that:

Anchor

The user need

Component

A single entity in a map e.g. an activity, practice, data or knowledge

Need

Something a higher level system requires. This is visualised by an Interface

Interface

A connection between components

With all those pieces, the 4 simple rules, and the definition of an Anchor, a Component, a Need and it’s corresponding Interface then you can relatively easily make a Wardley Map.

For more information on the symbols in a Wardley Map see Figure 61 in the Wardley Mapping Book.

A Wardley Map of “Me going to bed”

To prove to myself how easy it is, I thought I’d make a Wardley Map that I hadn’t made before using the above rules.

I have 3 kids at home, and 2 at university. I’m often the last one up at night, so what does a Wardley Map of the “user need” of “Me going to bed” look like?

I used the OnlineWardleyMaps.com tool to make this in a few minutes. There is a link here if you want to clone it and have a play yourself: https://onlinewardleymaps.com/#clone:TF2dVjDH9YyVjLthuC

A quick overview: each circle is a component and the “Going to bed” at the top is the user need or anchor. Needs are modelled vertically upwards so you can read

I started with the user need or anchor: I want to go to bed

And I thought about some of the things that need to happen.

I need to lock the door.

But I also need to check everyone is home before I do it.

And I need to put the bins out before I lock the door, otherwise I have to unlock it and lock it again.

All I actually need to do is lock the door, turn the lights out, and brush and flush. But these needs have other needs.

My wife and kids won’t be too happy if I turn lights out on them while they are still up. They can turn them all on again of course, but it’ll just annoy them.

I could have put turn lights out further to the right, because some of our lights are connected to our smart hub, and can be turned on and off from various apps. But some of them are not. And some of those lights get left on (which is annoying).

And my kids need to brush and flush before bed!

My wife needs to brush and flush as well, but that’s her responsibility, so I could probably remove that from this map.

But with just the anchor, component, need and interface and the 4 simple rules above, I’ve made a Wardley Map for the user need of “Me going to bed”.

A note on the evolution of the components

This map is very simple. The evolution of the components is relative, and my wife is definitely more evolved than me.

As I have noted the turn out lights could have been further right meaning it is more evolved in the map, because we have smart lights. If we got more smart systems in the house, maybe lock the door could move right, or maybe it would move left because it would actually become less evolved because locks and doors have been around for hundreds of years!

For my family, the map might be very different. They might see the need for locking the door as much lower down the map than I do. The interesting thing is that in essence, this map shows two separate chains of needs and they are connected, but I don’t think that connection isn’t really useful to add. Maybe turn out lights needs lock the door. That could be a useful addition to the map. All maps are incomplete, and imperfect and there are always ways of improving them.

The point is that for me those positions make sense for what I want to use the map for. If I showed this to my wife or my kids, they might well disagree about the map because the position of the components has meaning. Who knows? Maybe that discussion might lead to my kids going to bed earlier or maybe they can be responsible for turning the lights out!

Conclusion and your turn!

It is a simple concept to take 4 simple rules and build a Wardley Map. From that base, you can add on a lot of complexity, and gain much more insight into business, strategy and many other areas.

Let’s go over the 4 rules again:

For Wardley Maps:

1. vertical (see [2]) and horizontal (see [4]) position have meaning, but it is only relative to other elements of the Map
2. “needs” relationship are modelled vertically upwards
3. “anchors” are “components” that have no needs
4. each “component” on a Wardley Map needs to have an evolution “score” relative to all other “components” on the same map and this is modelled horizontally increasing (“more evolved”) to the right

Everyone has to start somewhere. Wardley Maps are often seen as complex and difficult. What I’m trying to do is make it a lot easier to simply start. That initial hurdle can be very large.

I reckon you can make a map right now.

Go to https://onlinewardleymaps.com/#clone:TF2dVjDH9YyVjLthuC and that should be a copy my “Me going to bed” map.

The interface is like this:

Pick a simple user need that you have. Make it something you can easily think about, and on the left hand side where it says “anchor” change where it says “Going to bed” and update it to whatever your user need is.

Then add your own components in.

And when a component “needs” another component you put “->” on a line on the left.

And when you are ready, you can share it with me on twitter — https://twitter.com/pauldjohnston — or comment on this post.

And I’m sure swardley — he’s https://twitter.com/swardley on twitter — would like to see it as well.

A bit of background

See this tweet thread for where this post came from (screenshot below):

Simon Wardley has created his example “cup of tea” Wardley Map without what are often thought of as the “normal” x- and y- axes of “Evolution” (x-axis) and “Visibility” (y-axis).

This image comes from this tweet (screenshot below):

Simon explains that the axes are there as “scaffolding” and to make it easier to understand. In other words, the axes are not necessary. It is clear that many people use these as parts of the map that are almost a requirement, because it’s difficult to understand without them.

This might be useful if you want to dig a bit further into Wardley Mapping.

He wrote a book on Wardley Mapping which is free on medium if you want to find out more.

His pinned tweet has more info on learning to map as well.

I’ve been trying to figure that one out for years.

I genuinely wish I could work out how to figure this out because there has been a huge need to get developers up to speed with serverless for several years.

The lack of a clear path from “developer” or “cloud engineer” to “serverless developer/engineer/architect” is startling given that this has been on the agenda for many people in tech for years.

“Our team doesn’t understand what serverless is”

I’ve worked with small teams, bigger teams, and very big teams. Teams who have been trying to develop startup applications on the web, on mobile and for enterprise and for consumers. I’ve also worked in scenarios that have very large teams where you simply have no way of working one to one with everyone and they are building some critically important applications using a serverless approach and they could last for many years.

One thing I have learned in all this: It is not easy to get developers to change their day to day approach to development (the approach they have learned either at work, or trial and error, or via the years of building software) to switch over to a serverless approach.

Developers are simply annoying.

I mean, not all the time. If you leave them alone to do what they want, they’re often great!

But if you ask them to change… there can be problems.

They are exceptionally opinionated about the way they think applications should be built, the way they think code should work, the way that you should write code in certain programming languages…

If you get a team of 8 developers, you’ll be given at least 13 opinions on serverless simply by mentioning it, and none of them have to have any experience.

And the issue is only exacerbated by how developers think about the “cloud”. I still don’t think we have a good definition of the cloud, but it doesn’t stop a developer giving you their opinion of what is good and bad about doing things “in the cloud” and “on premise” (although… “on premises” should be right but that’s not what we say, or are we talking about having a “premise” in the context of previous statements and propositions about which we then talk… because that would be about right sometimes).

Developers are exceptionally opinionated about everything to do with tech.

And it’s really annoying.

Because, and I say this really carefully, most of the time, developers are just very clearly, and very plainly, wrong.

Where developers are right about serverless

Serverless is not easy... to learn.

At least, serverless is not something you can go to a website and learn the syntax of in half a day or type in “hello world serverless” into a search engine and get 47 “Learn Serverless with these 8 neat tricks!” blog posts, and then find out that your years of building applications in “javathon” using the “railpress” framework are easily transferrable, much like many other skills have been in the past 15 years of working on internet and server based solutions…

In fact, when most people look for tutorials or definitive guides, finding the really good information on serverless is, unfortunately, far too difficult a lot of the time.

Minor rant about “serverless.com”

The whole idea is not helped (and I’ve said this from the changing of the name back in 2016 I think it was?) the serverless.com has really not helped here.

That is not to say that they are not good people (they are and there are some great people that work there), and it is not to say that there are a number of companies that have got a lot of value out of what they produce.

The problem is that serverless.com is just as opinionated as everyone else, and that comes out in the way it builds its solutions.

Note: And if you haven’t figured it out by now there are many more ways of building serverless applications than serverless.com and anyone else that is thinking “the name of the website/company might confuse people” well, it confuses me and I often have to have conversations about when things are related to their solutions and when they are not. It’s infuriating.

Back to finding it hard to find good information on “serverless”

So how do you find information?

Back before it was popular, there were a few people who… found each other on the internet. Mainly on twitter actually.

These were people like myself, Yan Cui, Ben Kehoe, Ant Stanley, Farrah Campbell, Jeremy Daly, Erica Windisch and a whole lot more (and are as deserving as the ones I’ve just mentioned off the top of my head) who ended up getting to know each other well in a whirlwind few years between about 2015 and 2020.

We talked a lot and spoke at conferences and setup conferences like ServerlessDays.io.

And we learned from each other. And we shared the knowledge we had, and how difficult it was to figure out some of the complexities of serverless.

We had different experiences from CTOs of startups (people like me) using the approach as a backend system with small teams, all the way up to the transformation of whole enterprises to a serverless approach with hundreds of developers.

And that led to a lot of content being created and shared.

Content like the Serverless Best Practices I wrote in 2018, which are still very relevant now:

Serverless Best Practices. Within the community we’ve been… | by Paul Johnston | Medium

We all knew then, and we still know now, it is not simple to build serverless applications.

We all knew then, and we still know now, that the tools we need don’t exist for what we want to do.

We tried. There were missteps, attempts to create tools that looked like things we’d had before, attempts to create new tools that would be helpful to the solutions we were building and we learned a lot of interesting things.

We also had to deal with an unhelpful amount of misinformation being spread. The “low-code/no-code” people who, at best were gently making fun of us, but in reality were belittling what we were trying to do in many different ways.

I’m beginning to think that there is a reason for why there is a struggle there.

And I think it’s something that we’ve all overlooked.

Serverless applications aren’t easy to understand from the outside

The majority of large scale serverless applications that are in production today are on Amazon Web Services:

Serverless Computing — Amazon Web Services

Other cloud companies and other serverless solutions exist, of course, and some of them are very good. However, the solutions that have tended to become well known are the AWS based solutions, built on a base of AWS Lambda functions and using a few key principles.

And when you take a look at the solutions that have been developed, and scrutinise them, and try to find a common thread to start to explain them to other people, one thing is very clear:

Serverless systems are not easy to understand systems.

Let me rephrase that: Serverless systems are not easy to understand systems, if you only use ideas and understanding that predates serverless.

The Cynefin framework is a useful tool here. It’s a “sense making” framework. A short introduction video can be found on youtube here: Cynefin Framework — YouTube

Cynefin explains that we manage and understand systems in different ways. The key is that most people do not know which of the 5 domains they are in when they are working (the centre is the 1st, or 5th, domain of confusion/disorder).

Most people are managing from within “disorder” (or confusion) because most people simply don’t consider what type of system they are working in or on actually is.

Most people simply assume that whatever system they are working on can be made to fit whatever model they like to work within. Does it need more rules, more management, more governance, more freedom?

The problem is that unless you identify the way your system works best (what domain it is in) you are likely to manage the system incorrectly.

How does Cynefin help with serverless application development?

The problem with moving to a serverless approach for developers is a very simple one:

In reality, a serverless approach is highly constrained and requires everyone to follow a few relatively simple principles over a long period of time.

In a very real sense, developers who work on serverless solutions will often complain that the serverless constraints are both confusing and are not justifiable from a technical point of view.

A simple example of some of the “constraints” might be helpful here:

My best practices from 2018 say:

• “Each function should do only one thing” and
• “use as few libraries as possible”

The AWS Well Architected Serverless Application Lens says that functions should be

• “Speedy, simple, singular: Functions are concise, short, single-purpose, and their environment may live up to their request lifecycle”.

In the AWS Lambda best practices it says

• “Minimize your deployment package size to its runtime necessities” as well as
• “Minimize the complexity of your dependencies”

Most developers I know find these best practices very confusing when they move to serverless.

After spending years having built software solutions where you can (almost) include as many libraries and dependencies in your code, these “best practices” are telling you not to.

And after spending years being told to create solutions that provide standardised and shared interfaces, and shared patterns, and classes and ORMs and all those things that people have been used to using inside and outside frameworks for years, these “best practices” are effectively telling a developer “don’t do that”.

Going back to Cynefin, the reason these exist, I would argue, is that the serverless systems we build are complicated systems and possibly in some cases complex systems.

The reason this is an important distinction to make is that most of the systems people have built up to now are essentially simple systems. I don’t mean that the technology in them is simplistic. I mean that the systems as designed could be taken and put onto other computers, and while it might be a little annoying, the reality is that those other computers could still run that software.

Caveat: I am not talking about systems that have been through multiple iterations over years, sit on a mainframe, have not been invested in or maintained properly and now the only person who understands how it works is Clive, and he’s retiring in 3 weeks. That’s bad management.

The type of systems we have all been developing for many years are the systems where you have some form of microservices architecture or “code” sits on a server/instance and interacts with a data layer.

But serverless solutions are different.

Most of the experience that a developer has had in their career will likely have been with systems that are not in the complicated or complex space and as such find acceptance of the best practices very hard.

The purpose of best practices

There is always a reason best practices exist. These practices have often been built up to sustain a particular way of working or to avoid mistakes.

The serverless best practices are, most definitely, an example of the avoidance of common mistakes.

I have worked on a lot of serverless systems and applications and have seen what developers do when they build these systems. I have seen the same avoidable mistakes made many times.

The best practices are much more about avoiding mistakes than they are about improving systems or efficiencies. Without them, systems are often slow, difficult to manage and maintain, and developers find it hard to understand what value they are getting taking the approach.

There is a purpose behind a constraint such as “minimizing the complexity of your dependency” (AWS phrasing) or “use as few libraries as possible”. The purpose behind this constraint is that an AWS Lambda function will initialise a lot faster when you constrain the dependencies and libraries.

The purpose behind “minimize your deployment package” is slightly different but has a similar outcome. When your function is first started, the deployment package has to be downloaded onto the runtime to run. The bigger it is, the longer it will take. Different runtimes (e.g. Java) are slower than others simply because they are bigger.

The purpose behind “Each function should do only one thing” and “Speedy, simple, singular” is even more difficult to explain to a developer. If your function only does one thing (singular) and you keep your code simple to understand, and you have made every attempt to ensure your code is fast, then the value you get is both in the efficiency of the invocation of the code and in the management and maintenance

These are not things that are obvious when you start to build serverless applications.

In fact, a lot of the best practices I have talked about over the years are almost completely counterintuitive.

Some may disagree with the above statement, but it is my experience with developers.

And unless a developer is prepared to accept that someone with experience and who knows what they’re talking about (e.g. someone like me or the people who put together the AWS Well Architected Serverless Application Lens would be good examples here), then it is understandable when a developer disagrees and finds it difficult to develop according to the best practices that are out there for serverless applications.

Sympathy for the Devilopers

I genuinely sympathise with a lot of developers who struggle with the switch to a serverless approach.

Switching to serverless is hard.

Switching to serverless is confusing.

Switching to serverless is counterintuitive.

The problem that I have is… I have seen what is possible with serverless.

When you understand what is possible with serverless, there is almost no technical scenario where a serverless approach is not the right one.

…and, whatever you may have read or heard from someone, the number of scenarios where a serverless approach is not appropriate is *vanishingly* small.

The number of solutions you cannot use serverless is diminishing daily.

The ones you cannot use it for is almost a rounding error to zero.

There are numerous highly regulated organisations using serverless (Banks, Pharma, etc) there are Governments, there are startups, there are everything and anything you can imagine.

Serverless came of age many years ago, is mature, and is not just about saving money by allowing companies to see how much each transaction is costing (Simon Wardley FinDev/FinOps thinking which came out of research in 2016), it is also replacing accepted cloud-based approaches for highly significant projects purely on the basis of simplifying the management and maintenance availability, scaling and at magnitudes lower cost.

Developers are soon going to have no choice but to learn about serverless applications and serverless solutions and what it entails.

So how do you teach someone to build serverless applications?

The strange thing is that… I’m not sure that you can.

At least, I’m not sure that you can very easily.

“You can lead a horse to water, but you can’t make it drink”

In my experience, a developer has to want to learn what it means to build a serverless application.

If a developer doesn’t believe that it is that important, and doesn’t listen to the best practice or take them on board, then it is almost impossible for that person to deliver a good serverless solution.

Some people have to go through that process unfortunately so that they come out the other side and realise why the best practices exist.

I have had to let developers release solutions into production, without saying anything, that I know have issues simply so that they can learn why what I have said previously to them is important.

The first step is actually the hardest: and that is getting them to start the journey.

Serverless development doesn’t lend itself to long gaps between releases.

And by “long gaps between releases” I mean anything more than a couple of weeks.

I mean, once you understand it, a couple of days is a long time in serverless!

I say this because developers learn more by doing and making mistakes, than they ever do by being told.

So, I’ve been thinking about this recently, and I think I’m coming up with a possible future approach to how we can teach serverless.

Learning Serverless: The Sweet Spot

The best serverless applications tend towards being highly event driven. I haven’t mentioned event driven architectures or EDA in this post yet, but I think it’s important to note here.

The best serverless applications also tend towards using Function-as-a-Service functions that are small, singular, fast functions. Not all serverless solutions use FaaS functions, but the majority do at present. While many people build FaaS functions, not many build whole applications, and therefore few learn the wider understanding of them.

The best serverless applications also tend towards using a low latency non-RDBMS data store. An example from AWS is DynamoDB. The reason being that the data solution was originally developed to maintain low latency at scale and these features make it an ideal fit with other characteristics of serverless solutions.

The best serverless applications also tend towards highly automated DevOps. When building AWS serverless solutions I have a preference for AWS SAM and the AWS SAM CLI, and I know others who will tell you of their preference for other solutions.

Applications rarely just happen though. It is very rare to find developers with experience of the kinds of solutions above who have not built serverless systems already.

In other words, this set of skills is unusual.

Many developers will also not have had experience of the range of skills outlined here, unless they have been the lone tech person on a small startup or something similar to that. It is unusual, especially in a larger company, for someone to have that kind of responsibility across all the disciplines.

And that is why it is so hard to find developers who are “serverless ready”, and you have to train them.

But there is a sweet spot.

And the sweet spot appears to be in the combination of three elements:

Event-driven thinking + “Speedy, Simple, Singular” Functions + Low Latency Data Layer development

The DevOps parts are, I think, the easiest elements to learn as you go, especially with a tool like SAM.

If a developer is prepared to accept the “Speedy, Simple, Singular” functions side of serverless, then they have already accepted probably the hardest concept in the whole of the best practices.

The data layer is not something that is easy to learn, but it is also not impossible. There are some very good resources out there for example for DynamoDB, for MongoDB and the support forums and networks are bigger than the serverless networks. In my view, all someone needs, is the understanding that “RDBMS” are not the only way to do data layers, and everything else can flow from there.

Event driven architecture (EDA) and thinking is possibly the hard one here. I’ve worked with people who think they understand EDA and bring preconceived ideas into serverless. EDA systems aren’t serverless, so bringing the ideas across that way doesn’t entirely make sense. However, FaaS functions such as AWS Lambda are almost always invoked by an event occurring. That makes events a really important managed subsystem to a serverless solution and understanding the different patterns that emerge from that can make a massive difference to the applications that can be developed.

That sweet spot, the event-driven, small-function, low-latency-data, sweet spot, that is where your serverless developers come from.

If a developer doesn’t at least grasp those concepts and accept that as a starting point, then it is arguable that what they are developing is not serverless but is an extension of non-serverless development on technologies intended for serverless.

Learning Serverless is hard but getting easier

All in all, learning serverless is hard.

The best way to learn is to do. Trying to build something serverless without the support of the community or certain tools has been very hard for years due to the lack of clear support and direction.

Hopefully that is changing.

The best serverless solutions are still AWS-based.

The best serverless solutions, I think, will stay cloud based as well. I’m not sure I see, at this point, many emerging solutions that I could genuinely call “serverless” that do not look something like AWS Lambda, DynamoDB, API Gateway, SQS and the other services that go with it.

I wish I could say that the other cloud providers have caught up in recent years. There have been some interesting service improvements, but AWS has worked very hard to develop joined up services.

The service that allows AWS to make the serverless solutions all work together is, believe it or not, Identity and Access Management (IAM). I have often heard how other cloud provider’s solutions are “better”, but I simply don’t see it. AWS has worked exceptionally hard to make their solution work. It is functional, understandable, and works. You can keep the bells and whistles.

“But what is a serverless solution?” (I hear you ask)

That is for another post.

But it is not defined by its technology.

It’s a strange thing to say, but that is true for me.

Although almost all serverless solutions come back to AWS Lambda, DynamoDB and API Gateway, they do not have to.

Now, in 2022, a serverless solution is one that is the easiest to run, for the least amount of effort, and still provides me with the required business value at the lowest (reasonable) cost.

My AWS bill is rarely above $5 a month, and I do a decent amount of trying new things.

My experiments are almost always a variation of using the AWS SAM CLI to throw together a set of AWS resources, usually API Gateway, AWS Lambda functions, events, SQS queues, SNS, EventBridge, DynamoDB, and maybe S3 here and there with other resources every now and again. I almost always build and tear down the resources every session. There’s not a lot I leave up and running, and even when I forget, it’s rare for it to cost me anything.

I’ve been running my AWS account like this or a variation of this for 7 or 8 years now. The most expensive thing on my account is some files I have on S3.

I reckon I’ve probably got the initial proof of concept somewhere for the original backend for the startup I joined in 2015. It’s probably very bad.

But I reckon it would still work.

And I reckon it would still be able to manage the load for a good few thousand people.

And it was AWS Lambda based.

And I can run all this at far far less than the cost of an EC2 server, and it’s all automated and managed for me.

Go and learn serverless. It’s never been easier.

The reason is that serverless systems are built on a foundation of building tiny and highly or completely decoupled systems within a much wider system.

Software systems and software engineering is predicated on interaction and interoperability.

The prevailing understanding of how to manage software development is also predicated on the idea that the solution that is created is by one team, is also interacting and interoperable with that of another team (coupled, not decoupled).

The problem is that if you have this mindset, then your understanding of testing, deployment and a range of other things within the development process are misaligned.

Serverless systems should be (but rarely are) thought of as a large number of decoupled but very small systems, that are completely independent of each other, connected by events.

Yes, that’s “software” in the general sense.

But that’s not “software” in the sense that most developers or managers think about it.

What are serverless systems if not (traditional) software systems then?

Serverless systems then are a highly decoupled, event-driven, distributed system, with small, highly independent pieces of software that rarely need to know about any other pieces of software.

When you think about the system like that, then the way you structure your teams and the way you develop the software is not the same as if you are developing a backend for a website on a server (even if you’re developing a serverless backend for a website).

One of the biggest differences, imho, between a normal software (or server based software) project and serverless is testing.

The high decoupling element within a serverless system means that you don’t have the same requirement to test across teams.

Each single element needs testing (this doesn’t change) but because each element is decoupled (or should be) and is small (or should be) then there should be near zero coupling between teams and between elements.

If there is near zero coupling between teams and elements of a system, then… you just have to test the elements (except where there is coupling where you have to test).

The serverless processes

So, the development process becomes about building a lot of small and decoupled elements, and testing them.

The wider management process becomes about understanding how those small and decoupled elements fit together.

The initial design work becomes about designing the data flow for the entire system so that you can ensure that elements are right sized and designing your data layer around it.

If you design it right, you can significantly limit your testing, because your system can generate really clear error messages.

If you manage it right, your teams can deliver small pieces that fit into the wider system without recourse to any other teams.

And if you get your software development within the teams right, your testing should be clear enough to catch a large number of errors (in a small system) before you push anything into production.

And once in production, each element is independent, so it is easy to update each element without harming the overall system, and when a bug occurs, it is easy much faster to fix.

The title “Serverless systems aren’t software systems” is intended to get you to read the content.

Because of course serverless systems rely on software, and underneath it, they are software.

But in reality, serverless systems are not software systems that the vast majority of software developers, software managers and software professionals are used to and comfortable working with.

The issues around building serverless systems are not insurmountable. Most developers and managers get there in the end. But it is not a straight forward journey to get there, and can have some big bumps in the road.

And this is the problem.

If you treat a serverless system like “just another software system” or “it’s just like X we’ve done before” then you may well have issues delivering against it.

There are a few people who grasp how to deliver these systems very fast, and often they come from an enterprise, and a banking background (in my experience), and not a startup background.

The management of building a serverless solution does appear to need either different skills, or the need to adjust your understanding of how to deliver a solution.

Learn and adjust before going serverless

The reason my title says what it says is simply to say that if you treat a serverless system as a software system, and try to build it that way, you are far more likely to struggle than you are to get the best outcome.

Learn your tools.

Learn why they exist.

Learn how they can best be used.

Adjust accordingly.

Building serverless solutions can be amazing.

Building serverless solutions can also be really hard, and sometimes an experienced person (like me) can seem like they are telling experienced professionals that they don’t know what they are doing.

Building serverless solutions is a new skill.

Stop treating it like an old one.

There are some transferrable elements, and some transferrable skills.

But if you are determined to do it your own way, and it doesn’t quite work, then don’t blame “serverless”.

[This blog was created from this original tweet thread]

The story of an 18 year old shooting 19 kids and 2 adults at an elementary school in Uvalde, Texas should be enough for any country to decide that gun control should be a top priority.

But it is not. Because it is the United States.

The United States is The Bad Place

Between January 1st 2022 and May 25th 2022 there have been 213 mass shootings in the United States (source Gun Violence Archive stats and Gun Violence Archive map).

213.

For context, pretty much nothing like this happens anywhere else in the world.

ANYWHERE.

Even when a mass shooting occurs, which is highly unusual, it is often years between significant events.

Take a look at Europe, a continent with (give or take) double the population of the United States, and many sovereign states with many different laws.

The Wikipedia entry has some of the mass shootings in Europe, but we’re going back over 20 and 30 years for some of them.

And many of those mass shootings were responsible for gun reform in those countries and led to huge reductions in gun violence.

So what has this got to do with tech conferences?

The tech industry largely centres around the United States. The biggest tech companies are based in San Francisco and Seattle, whether we like to tell ourselves that we are a distributed industry, we are still drawn to these two cities from around the world and a few other locations for conferences on a regular basis.

There are many tech conferences that occur in the United States, and these attract international speakers and attendees.

It has only occurred to me in the last day or so that:

There are guns at tech conferences in the United States.

Let’s say it again:

THERE ARE GUNS AT TECH CONFERENCES IN THE UNITED STATES.

Do I have proof? I have several people who have said they have seen guns at tech conferences in my twitter DMs.

I have a black British friend who has described an incident at a US tech conference where they pointed out someone openly carrying a gun to security. My friend was then confronted by security curious as to who he was and why he had made the report.

Understand? As a black non-US man, reporting someone for carrying a weapon (in hindsight it was not illegal) was considered suspicious.

Why? Because in every other country, it is very suspicious for someone to openly carry a gun anywhere, let alone a tech conference.

In fact, being straight, white and male means that I almost certainly do not see any real issues going to tech conferences in the US.

I am just accepted as part of the club.

But we need to surface these stories, and identify the values we need to hold as a worldwide tech community.

I and others with that privilege need to speak for those who have to live with the stress of not having that privilege. Even though they have been saying it for a long time.

There is nowhere else in the world that I can think of where a tech conference could be held that guns would be openly carried without some sort of licence or permit. Even then… it would be very strange.

The only reason that it is tolerated in the United States is because that is where the big tech companies are, the startup money, and lots of the people, which means that we all have to go to them.

And, no, your constitution is no defence. Your politics is your own. We find your politics both reprehensible and bizarre on guns.

And politics gets to be more important than safety when you start carrying guns at tech conferences.

Proposal: #NoGunsInTech in all tech conference Codes of Conduct

As an international visitor to the United States, I have rarely felt worried about gun violence.

But I am a straight, white man.

We need to make it safe for everyone who comes to tech conferences, and the tech world should not submit to US politics and just accept their inability to fix gun laws, when pretty much the rest of the world has managed to do just that.

So I am asking all tech events held in the US to adopt an addition to their Code of Conduct that bans all guns from the event.

I suggest it goes something like this:

“We recognise that technology is a global community, and as such we want to make all attendees feel safe. Irrespective of political belief, all guns are banned from this event to ensure that all attendees whether from the United States or from abroad can be assured that there are #NoGunsInTech.”

If someone has better wording (I just made this up) then great.

And before someone asks: YES this should be enforced by the conference organiser.

And attendees should require it too.

I would love it if the big tech conferences adopted this.

Maybe we could have a “#NoRifleInvent” or a “#GoogleNoPIstOls” trending.

Maybe we could have “#ServerlessDays” being “#GunlessDays” too.

Tech will not save us

As with many major issues in the world, such has Climate Change and Covid, the tech world often thinks that “tech” is the solution.

In fact, the biggest culprit when it comes to inaction often appears to be large parts of the US tech community (note: not all but definitely large parts). The expectation is that there is a way to make something clever out of software, hardware, or new tech that will fix the problem and make it go away.

I’ve seen “there’s this gun with GPS so that it will only fire in certain locations” and “what about facial recognition or AI?”.

I’m sorry to tell you (again — because I’ve written about this before):

More tech will not save us.

This is a politics problem.

This is a people problem.

This is a people in power playing politics problem, and it has been for decades.

Gun violence in the United States is not going to get solved by tech, and anybody that thinks it is, makes it worse, so just don’t do that.

And, yes, I am a British person, speaking to the United States tech community, but, to be extremely blunt, the United States tech community is not leading on this issue. Somebody needs to say something. Maybe nobody will notice this blog post, maybe someone will. But at least I’m proposing something that has a hope of starting useful conversations and starting to ask some important questions.

And hopefully, this will start to make everyone in tech in the US realise that people arriving for tech conferences do not have to accept your politics. We can push back, and challenge your politics, and tell you to do better.

Move your conferences

If you can’t do the above, because it is too political, maybe then you should move your conferences.

I like Vancouver.

I’ve never been to Mexico, or the Carribean, but I’m sure they have great venues for conferences too.

And Europe is full of great people and fantastic venues.

Hey why not Africa too?

Maybe it’s time the Americans started to realise that the rest of the world has better gun control and that they would do well to go and learn what it looks like to be in a country where guns just aren’t a problem.

But… let’s start with #NoGunsInTech for US tech conferences.

Share this widely if you agree.

Ventilation, is what yah need. Apologies for the Roy Castle reference… I couldn’t help it.

Anyway, back to what happens when you build a garden office. It’s often a separate building, small, and one of the big criticisms is that it’s difficult to regulate the temperature. It’s either too hot in summer, or too cold in winter.

It’s cold because the building either has lots of ventilation — vents, windows and doors need to stay open because of the heat in summer — or none — it’s too cold to open the windows and doors to provide ventilation and the heat needs retaining.

Garden Offices have no ventiliation

The point is that almost no garden offices provide good ventilation. Well… that’s not quite true.

Most garden rooms rely on things like trickle vents in the top of double glazed windows and doors. Trickle vents are there to provide “natural ventilation” — Trickle vent — Wikipedia. Basically, they’re a small hole that you can open and close without opening the whole window.

Now, when you’ve spent a decent amount of time making your building really well insulated, putting in a trickle vent, or putting in a hole is a silly idea. The whole point is to try to control the air going into and out of the building so that the heat is retained and the temperature controlled (either removed or retained).

When you have two different air temperatures and an impermeable barrier (like a wall) then the insulation is what determines the speed at which the heat is exchanged between the two and then equalises. That’s why insulation matters. If you have something like a window in between, and you open it, then that just make the equalisation of the temperature between the outside and inside air. The problem is, in a small building, the inside air is going to change to the outside air temperature very fast.

Essentially to reduce your energy usage, if you can minimise the heating or cooling needed via limiting the need to open up windows and doors, and make the building as air tight as possible, that is the best solution.

Enter “Mechanical Ventilation Heat Recovery” MVHR

So, with a little searching of the internet, you find that buildings need ventilation.

Why? Because without ventilation, the room will retain moisture, and things will start to rot (moisture + time + pretty much anything = bad). So you need some way of having air flow, and reducing moisture.

Enter MVHR. These systems are built to “recover the heat” from the inside environment, while removing the moisture and pushing it outside.

Heat recovery ventilation - Wikipedia

Most MVHR systems unfortunately are built for “whole house” systems, and finding systems for “single room” buildings or similar is much more difficult. Some do exist, although they’re designed more for studio apartments, or for a hotel room, so it’s not quite the same scenario. But the principle is the same and so it’s possible to put in a form of ventilation.

One other thing about MVHR systems is that they reduce the need for heating and cooling, because they regulate the temperature. They aren’t air conditioning, or heaters, but they can significantly reduce the amount of heating or cooling that is needed in a house, and therefore in any scenario they are used. If you add things like blinds to the windows in the summer and ensure that there is a good retention of heat then MVHR should prove very cost effective.

I’ve found single room options for around £250–£400. I’m not sure which ones are good or bad, but with a little more searching, I don’t think it would be too difficult to figure out. It’s not cheap, but I’m pretty certain it would save money in energy costs relatively quickly.

And it’s easy to retrofit!

There are other options

If you look at ventilation, there are other options out there such as passive ventilation, which is basically open vents again which in an air tight system isn’t going to work well. There are also positive ventilation systems that push air into the building and expect the air to escape through cracks or vents, but this again is not good in a building you’ve spent time trying to make air tight.

And as has already been said, no ventilation gives other problems later on with condensation and later rot.

Environmental considerations of MVHR

Anything that reduces the need for heating and cooling is a very good thing. In fact, it’s pretty clear that if you can build a close to air tight and insulated building and use something like an MVHR to regulate the temperature and reduce energy consumption, then you end up overall building a more energy efficient building overall.

This is a very positive thing and should be something that everybody should consider.

It is not something I see as a selling point in almost any garden office building companies (although I think The Garden Office Pods are one of the few that do but it’s not clear). Most of them don’t talk about ventilation, because most of them don’t make their buildings to a high enough standard to need that kind of ventilation… which should tell you something.

So… what’s next?

Planning maybe…

Ventilation… Oooh ventilation… was originally published in I want a Garden Office on Medium, where people are continuing the conversation by highlighting and responding to this story.

So after all the discussion about insulation it’s clear that the options that are out there to be “environmentally friendly” while building a garden office, and also build something that isn’t going to cost a fortune, while also doing something that isn’t going to be impossible to either self-build or get someone to build for me is going to be… difficult.

I spoke to one company, who, if you have the money, are definitely a company that you should talk to if you don’t want to go the self build route. I have no affiliation, reason to say this or whatever, but they are just a company I think are worth talking to. (Huub also happen to be based in Poundbury in Dorset, which is an urban extension to Dorchester where I grew up, and has an interesting history in terms of architecture which is in large part due to the Prince of Wales).

That company is huub — Huub Garden Buildings:

Huub have some amazing eco builds. They are not cheap. But you can learn a lot by looking at what they build and how they build them. They also build with solar panels, and batteries, and understand issues around insulation, materials, reuse and a lot of things that most companies won’t understand and certainly most people doing a self-build won’t know or consider.

All about the base

I did talk with Huub about the possibility of them building the smallest building they do in our garden. This would have been just inside the budget, but it was not big enough in terms of size. It also didn’t have solar panels, or anything like that, and was very straight forward. It did have great insulation and fantastic wood cladding.

It also didn’t use a standard base. Most builds that you see use a concrete base, or concrete blocks, but huub use a recycled plastic eco base. It’s a plastic mesh made from recycled plastic, that can take a significant amount of load. It can also be placed directly on top of a grass (with a bit of builders sand to ensure surface is flat) and spread the load. There are lots of examples on youtube like this one:

And you can add a bit extra around the edge with some to add a drain (this is important for buildings to ensure they don’t get rotten around the base and foundations).

This is not something that many builders will do. But it’s really much much better for the environment to use recycled plastic than it is to use concrete anyway.

If you weren’t aware, concrete is bad for the environment.

And then…

Screw it!

Another friend told me about these amazing things called ground screws. These are exactly what you might think they are. They are screws that go into the ground. They also look a little comedic, as if, somewhere there is a massive giant with an enormous screwdriver, but if you can get over that, these are pretty amazing.

These can come in smaller sizes, and can be installed without professional support, or a professional can come in, and install them for you, and install larger ones.

A big advantage of these is that you don’t need to dig. You can install these where there are tree roots (it would go through/round them), they go deeper than you would normally dig (and very quickly) and they can take a lot of load (depending on where you live of course).

The point is, if you want to be even more sure of your foundations (without using concrete), then ground screws, even the smaller self-install version, are a fantastic option. Here’s a YouTube video to show how easy it is with the self-install version:

Ground screws are made out of metal, and claim to be much more environmentally friendly than concrete. That claim does appear to stand up. They are reusable for one (you can remove them and replace them) and some ground screw manufacturers claim over 75% of the materials are from recycled sources. There is a lot to like here.

And with some ground screws having a flat “SIPs” bracket, then you can lay SIPs flooring directly onto the top of ground screws (with the correct protective and breathable layers around it) without the need for a frame (which is how most ground screw brackets are used).

So the base…

It looks like the base is probably going to be ground screws, although they aren’t as cheap as other options. They do allow for installation on slightly uneven ground as the screws can be different heights and levelled with a laser. This make it much much easier to make a building flat too.

And it looks like a much more environmentally friendly option to go with ground screws than concrete, while giving very solid foundations as well.

So ground screws and SIPs seem a very good match.

If you look at some of the ground screw installer websites, they even give some hints and tips on how to build a building with ground screws and SIPs, but that doesn’t make it easier:

Build a SIP building with ground screws — Stop Digging!

They make it sound so simple… but then you hear words like “ventilation” and everything starts to get a bit… difficult.

Next post: Ventilation… Oooh ventilation

#An… attempt to be based was originally published in I want a Garden Office on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this little saga, I had come up with some rules as to why I wanted a garden office:

1. I needed a space to do actual work. Simply put, a desk and a computer, and quiet where I could have video calls as well.
2. I needed a space that would work in summer, winter and in the evenings, so a “glorified shed” without good insulation or heating would not be good, so I needed to consider that
3. I needed the space to work in the garden and be usable by others. It wasn’t just going to be “my space” but might have to be repurposed as a garden space. The garden isn’t big. This is a big consideration.
4. As environmentally friendly as possible. I’m not just going to concrete (bad) over a bit of the garden and dump a plastic filled monstrosity on it, however “aesthetically pleasing” it might look. Let’s see if it’s possible to make it good for the planet and work for us too.

Given all of that the first thing that really mattered was how to make sure that the garden office was both quiet and well insulated while also being able to stay cool in the summer with the sun out.

There is a lot of information about this when it comes to buildings but not when it comes to garden rooms. The assumption is that your garden room is largely a summer room only, and you really shouldn’t need it in the winter, or if you do, then here’s a heater.

When you start to look at garden offices, and garden rooms, what you find is that while they may say “insulated” what they mean is that the walls and ceiling may have insulation, but it is not unusual to find that the floor does not. When the floor does not have insulation, you find that your feet get cold, and the room does not retain heat as well (even though hot air rises, it will still escape). Also, it depends on how good the insulation actually is.

Insulation and “R-values” and “U-values”

When talking insulation you want to know about the R-value and/or the U-value. Essentially the R-value is how much heat is lost, or how “resistive” whatever material you have is to losing heat. See https://en.wikipedia.org/wiki/R-value_(insulation) for more info. The U-value is the inverse.

Also, most materials are rated against “approved installation”. If you install it badly, the R-value gets worse. Also, doubling the thickness tends to double the R-value (not always, but close).

To get an idea of how different materials can provide wildly different R-values, there is a table on wikipedia: https://en.wikipedia.org/wiki/R-value_(insulation)#Typical_R-values. Most of it is below. What you can see is that manufactured insulation materials have a significant advantage over what might be considered “good” insulation materials.

Garden offices are not well insulated

When you start to look into the insulation of a lot of “garden rooms” and “garden offices” many of them are not well insulated. They might have some insulation, but it will be the same kind of insulation you might get in a loft space, or a bit better, and that’s not bad, but it won’t be great.

Not only that, but it will often be added into the “gaps” in a wooden frame.

I took a still from this youtube video: https://www.youtube.com/watch?v=UWQqGBsqfI4

Now, this is pretty good as it goes and it’s way better than not having anything. But it’s bespoke. Someone has to build it that way. To install it you have to put in expanding foam around each edge as well to install each insulation board to ensure it’s air tight. The downside is that you’ve got insulation + wood. Wood is pretty good insulation, but it’s not perfect. The upshot is you’ve probably got an R-value of between 3 and 4 at this point, which isn’t bad, but could be better if the panels were just laid on top (which you wouldn’t do, because they aren’t meant for working with like that).

And they insulated the inside the same way but with 50mm foam not 100mm foam, which… reduces the R-value. They put 100mm on the roof which is good (heat rises).

Now, in some ways, I’m not criticising. This is actually a good build in comparison to many I’ve seen. It has insulation (and there is also sound proofing which would add some insulation too). But the problem is that this is very bespoke and very time and labour intensive.

In other words, this isn’t your normal “I need a garden office” solution. This is your bespoke “build me exactly what I need” solution.

SIPs panels

So I start talking to people and find out about SIPs panels:

Structural Insulated Panels

Structural insulated panel - Wikipedia

Most people outside of the construction industry (or compulsive viewers of TV shows where someone with too much money does a self build somewhere ridiculous) wouldn’t have heard about these too often.

They are a sandwich of two OSB boards, with some form of insulation (usually polystyrene) between them. They are strong enough to be used as walls for houses, and they have inherent insulating properties.

You can literally build houses with them. Just search YouTube for “SIPs house time lapse”

This felt like a good thing to build a garden room out of. If I could find a supplier.

And there are a few companies out there who do garden offices using SIPs.

RESULT!

But… they’re quite a bit more expensive than the glorified sheds, or the lower quality insulation solutions.

Unless you’re prepared to “self build”.

Um… right.

Next post: An… attempt to be based

Brr… it’s cold outside! was originally published in I want a Garden Office on Medium, where people are continuing the conversation by highlighting and responding to this story.