sourceless

My reading was that there were two paths the author highlights:

1) Increase deployment capacity (which I'm reading as frequency, and I fully agree with)

2) Increase change capacity per deployment by making it less likely that a set of changes will fail through tests, monitoring, structural, and team changes

#2 is very much geared to "ship more changes in one deployment" which is where my disagreement lies. I think you should still do all those things, but that increasing the size of the bundle is explicitly an anti-goal.

I think you're better off, as a rule of thumb, making fewer changes per deployment if you want to reduce risk.

But -- that is my particular reading of it.

I think we may be violently agreeing - I certainly agree with everything you have said here.

That's indeed how I wrote it, but I could have worded it better. Very much agree that the insights in The Goal go far beyond the scope of The Phoenix Project.

I am disagreeing with the conclusion of the article, and asserting that more and smaller deployments are the better way to go.

I think unfortunately the conclusion here is a bit backwards; de-risking deployments by improving testing and organisational properties is important, but is not the only approach that works.

The author notes that there appears to be a fixed number of changes per deployment and that it is hard to increase - I think the 'Reversie Thinkie' here (as the author puts it) is actually to decrease the number of changes per deployment.

The reason those meetings exist is because of risk! The more changes in a deployment, the higher the risk that one of them is going to introduce a bug or operational issue. By deploying small changes often, you get deliver value much sooner and fail smaller.

Combine this with techniques such as canarying and gradual rollout, and you enter a world where deployments are no longer flipping a switch and either breaking or not breaking - you get to turn outages into degradations.

This approach is corroborated by the DORA research[0], and covered well in Accelerate[1]. It also features centrally in The Phoenix Project[2] and its spiritual ancestor, The Goal[3].

[0] https://dora.dev/

[1] https://www.amazon.co.uk/Accelerate-Software-Performing-Tech...

[2] https://www.amazon.co.uk/Phoenix-Project-Helping-Business-An...

[3] https://www.amazon.co.uk/Goal-Process-Ongoing-Improvement/dp...

As someone with astigmatism, the glow on the text makes it near impossible to read.

Teaching maths without "Maths Language" is like teaching programming without a Programming Language.

This is, unfortunately, a misconception.

Sure, a bullet the same size or smaller will 'fit' in a given barrel, but a depending on its weight and dimensions it will, at best perform equally, and at worst destroy the barrel.

But a bullet isn't the whole story; the rest of the cartridge has to fit snugly for the action of the gun to lock properly. Again, best case - the gun doesn't fire. Worst case, the action blows up.

This is a pretty simplified overview, but unfortunately the assertion above is a (pretty absurd) myth. Sorry :(

Second they enforce this, I'm unsubscribing

It's not homoiconic, which makes it not a lisp for me.

St Wulfram's in Grantham (https://en.wikipedia.org/wiki/St_Wulfram%27s_Church,_Grantha...) is just a little shorter than St James, and still has its original chained library (https://en.wikipedia.org/wiki/Francis_Trigge_Chained_Library), which has been claimed to be the oldest public library in the UK!

Sounds like you are being overworked. A 9-5 as an Eng Manager is achievable, but you might need to jump ship to find it.

Working late has a huge knock-on effect on your social life and ability to interact with society around you. That's probably contributing to your burnout.

If there's budget or willingness, having someone in that timezone who can perform your role for that meeting may be possible.

I'd be very wary of taking any regular work outside of your contracted hours unless there is a lot of $$$$ involved and your relationships can survive it.

You might get some mileage out of a long vacation, or agressively pruning your work hours.

And you get to inherit all the vulnerabilities while sacrificing the ability to automatically/easily upgrade to a fixed version...

I've been working on something like this (though written using CLojure & core.logic)!

I'm glad to see there's someone else out there who think's it's useful.

Thanks for your comment - and agreed!

Last year I taught myself a good deal of category theory, and you're right, five minutes is not really enough to learn most things - but it is enough time to start an exercise - and those five minutes often turn into something longer!

We used this to make updates to the NHS Patient Demographic Service (which stores names, addresses, contact information). The records are pretty detailed (FHIR) and there's a lot of business rules and deep nesting.

It worked really well, and our users had no problems making JSON Patch requests.

Fantastic. First time I saw something similar to this was Edwin Brady’s recent demo of Idris 2. It’s quite amazing just how much of a program can be machine-written when the types are strict enough.

I hope holes & case-splitting get into many more languages.

I don't know, some of that is at least starting to happen with Idris 2, though not in the exact way predicted: https://www.youtube.com/watch?v=mOtKD7ml0NU (Type Driven Development with Idris 2)

Short summary of linked video: when your type system is powerful enough you can restrict the set of possible implementations to the point that the compiler can make a decent guess as to what the program should be to satisfy the type signature.

It'll certainly be the jump point for me -- I'm even holding back a much needed hardware refresh until BattlEye is supported on linux.

> having this kind of convenience let you be lazy about design

Or, conversely, this kind of correctness by construction allows you to focus on parts of the program that could suffer from non-trivial bugs

Yep. Your average SV engineer might be able to afford a Tesla and still have plenty room to spare in their budget, but your average EU-based engineer doing the same job is never going to get anywhere close.

Fantastic! Feels like it's been a dead project for so long, it's good to see it's properly back and fully modernized.