51–60 of 65 posts
Earlier quoted context omitted.
They were/are helpful in making medicine safer too. https://www.newyorker.com/magazine/2007/12/10/the-checklist https://www.ncbi.nlm.nih.gov/pubmed/24116973
The New Yorker article was later expanded into an entire book of the same name.
Earlier quoted context omitted.
Sure, and I guess my point is: If you haven't invested in those things, waterfall-esque deploy processes are just as bad and perhaps even worse because there's more chance for confounding changes to cause a nasty error. The only reason waterfall-esque deploy processes work without those things is because companies often waste tons of people-hours on testing things out in the staging environment (which requires time,…
The thing you're missing is that you're amortizing the cost. Yeah, it's typically prohibitive to run the manual testing on every CL. However, if you have any manual testing you need to run, then at some point you have to batch the changes & test them out together anyway. Automated tests don't necessarily solve this problem either. 1) Some automated tests can be time-consuming & so require batching of CLs to run too 2…
Wait, why is that? Manual testing should be reserved for workflows that can't be automatically tested (or at least, aren't yet).
I'm not sure I see why doing any amount of manual testing would necessitate manually testing everything.
> Some automated tests can be time-consuming & so require batching of CLs to run too
I'm not sure I see why this is a problem, and CD certainly doesn't require that only one changeset go live at a time.
> it's impossible to predict if you are going to catch all issues via automated testing
This is also true of manual testing.
> there's always things it's easier to test for manually.
I'd go further and say it's almost always easier to test manually, but the cost of an automated test is definitely amortized and you come out ahead at some point. That point is usually quicker than you think.
> I would think you need a structured mechanism...
This paragraph is entirely true of traditional deploys with long cadences as well. The need (or lack thereof) for very formal and structured mechanisms for rolling back deploys doesn't really have much to do with the frequency that you deploy.
> Now for web development this is fine since it's not touching any databases directly.
Maybe we're speaking about different things here, but the trope about web development is that it's basically a thin CRUD wrapper around a database, so I'm not sure this is true.
Earlier quoted context omitted.
I've been convinced that checklists are great (by theory and by practice), yet I still write way fewer than I should. I strongly dislike repetitive mental work, and writing a checklist is essentially resigning myself that such work will be necessary. Until I write it, I can still convince myself I'll be able to automate the process.
I use checklists to turn mental work ("uhh, let me think, what all do I need to do...") into straightforward physical work ("check, next step..."). I also use checklists as a first step towards automation and a stopgap until automation is complete, since I live in a constant state of infinite backlog. If I run through the checklist a couple times and it seems to: [ ] Cover everything [ ] Not require complicated decis…
Earlier quoted context omitted.
I am in favor of (check)lists for everything. I am actually surprised about how few developers take notes and make list. It’s one of the most important part of my workflow.
I've been convinced that checklists are great (by theory and by practice), yet I still write way fewer than I should. I strongly dislike repetitive mental work, and writing a checklist is essentially resigning myself that such work will be necessary. Until I write it, I can still convince myself I'll be able to automate the process.
At least that's what I keep telling myself. I also write much fewer checklists than I should.
I am in favor of checklists for certain critical tasks, even if they are repetitive and/or boring. I think checklists are underrated.
I am in favor of (check)lists for everything. I am actually surprised about how few developers take notes and make list. It’s one of the most important part of my workflow.
If I had to switch to some other note taking platform it would probably break my flow enough that I wouldn't do it.
One of the things I think about when analyzing organizational behavior is where something falls on the supportive vs controlling spectrum. It's really impressive how much they're on the supportive end here. When organizations scale up, and especially when they're dealing with risks, it's easy for them to shift toward the controlling end of things. This is especially true when internally people can score points by ass…
I am in favor of checklists for certain critical tasks, even if they are repetitive and/or boring. I think checklists are underrated.
One of the things I think about when analyzing organizational behavior is where something falls on the supportive vs controlling spectrum. It's really impressive how much they're on the supportive end here. When organizations scale up, and especially when they're dealing with risks, it's easy for them to shift toward the controlling end of things. This is especially true when internally people can score points by ass…
Having recently escaped from a "control and blame" environment, this is also horrible for releases as left unchecked, more energy is expended trying to double-down on architecting for perfection in fault tolerance. Risk aversion goes through the roof cripples decision making, and before you know it your entire team of developers have become full time maintenance coders, you stop innovating and spend cycles creating i…
[1] https://www.amazon.com/Why-Does-He-That-Controlling-ebook/dp...
However - I would want to caution: I think this model works because Slack has a self-described "culture of developer trust". I tend to think, they hire bright engineers and ensure they are equipped to do the right thing. I believe the vast majority of organizations are NOT ready for this. I direly want them to be, but simple fact is there are too many mediocre developers, and they can't be trusted without guardrails (and some straight up need babysitters).