Liz Fong-Jones (方禮真)Ovjeren akaunt

"Zombies will keep going until they either trip over something or eat your face." --@jessitron #DeliveryConf

Software that stays alive rather than becoming a zombie requires a _team_ to support it, not just one person. #DeliveryConf

The tools are a _part_ of the sociotechnical system. There's mutual learning involved, which is the process of symmathesy. #DeliveryConf

Quality code is consistent, modern, regularly deployed, and _observable_. If you don't deploy every single week anyways, then you'll have to go through hell to deploy security updates every month. #DeliveryConf

Your people need to be in stable teams, who understand the technology, the purpose it serves, and who the customers are that we're delivering value to. #DeliveryConf

We also need a _relationship_ between the people and code involving ownership and communication. Can we _account_ for what the code is doing and why? this requires really good _events_. #DeliveryConf

and there's an overall environment that the people and code exist in - are we adequately funded? are we having conversations over priority? are we connected to needs of the business? You cannot treat software as a one-off capital expenditure that's "done". #DeliveryConf

"Companies should be powered by software, not subject to software." --@jessitron #DeliveryConf

There's only so much software a team can support. The limit isn't the speed of typing, it's cognitive overhead on how much we can _know_ and meaningfully make decisions on. #DeliveryConf

.@jessitron gives a shoutout to @manupaisable et al's _Team Topologies_. Types of cognitive load: (1) Germane business-relevant complexity that _adds value_ (don't make teams cross multiple domains!) (2) Intrinic load required for the job eg frameworks, runtimes (3) #DeliveryConf

(2) cont: maybe don't use too many different frameworks and programming languages to avoid too much context-switching & overhead... (3) Everything else, the extrinsic load imposed by your environment. Timesheets, health insurance, external processes... #DeliveryConf

In an ideal world, you shouldn't _have_ to know exactly how your CI system works, your code should just go to prod. #DeliveryConf

Pull as much cognitive load out of teams, so that you don't need 100 people scattered across many teams to support the service, you just need 10 people on one team. This requires both automation _and_ cultural change #DeliveryConf

The value of automation doesn't come just from writing code for yourself; it comes from sharing that consistency with other people so they can benefit from it too. #DeliveryConf

There's a difference between alphabetizing the glossary once, and making sure it's _continuously_ done so any additions to the glossary get automatically alphabetized. #DeliveryConf

[ed: I love @jessitron's talks so much that I am 100% forgiving the fact that she's showing the tech of her former employer, which would be a pitch, but she no longer works there!] Tools like @atomist can be pluggable frameworks to standardize your workflow. #DeliveryConf

The easier it is to keep something alive, the more likely it is your team will be able to keep it consistent and updated. Take the boring work out of the hands of humans, and free them to do the interesting work. #DeliveryConf

You also have to be able to understand your tech debt. Where are your haunted graveyards that nobody's touched in a year? What things lack licenses? #DeliveryConf

Overall, we need event pipelines to decouple our workflows. The same way we decoupled data producers/consumers with Kafka, we need to get software delivery into decoupled pipelines managed by code. Waiting is for machines, not humans. #DeliveryConf

The instant you "hand off to the DevOps team", you've messed up Step 1 of DevOps. So this means everything needs to be software as a service, on a platform... why do we have to run these platforms and SaaS ourselves? #DeliveryConf

The answer is no, you DON'T want to keep the platform alive yourself. All you want to do is add the bits that you personally need, but push outside your own domain things that become stable enough. Use Kafka as a Service. use managed Kubernetes. #DeliveryConf

Pay other people to keep software alive for you, kill off your own zombies. Outsource everything you can. #DeliveryConf