Fail fast. But also... someone in a different area screwed up really bad.... so everyone can now enjoy this turning kit on productivity called a change freeze... it may be lasting for months... also... we're going to be putting a higher emphasis on productivity. So do more, but also, don't. Because we're freaking idiots.

hmm, I think "fail faster" and "feature freeze" go together as well as gasoline and fire.

Failing fast makes sense in a rapid iteration environment. Deploying on dev servers and testing rapidly with fast pipelines, low downtimes and many eyes on the code and results. But when a feature freeze is approaching and some of the higher envs are going to be frozen (Staging, QA, whatever you have) then the rapid iteration should slow down well ahead of time (honestly, if feature freeze is approaching, chances are your product should no longer require a lot of iteration anyway, just bug catching and manual testing but no new features added at this point)

point is, there should probably be a clear decoupling of those two concepts because to me it's obvious they can't work together in parallel. If you keep iterating on dev while analysis is taking place, you're going to render the analysis useless by changing too many stuff anyway. should wait for results and bug reports

@Hazarth I would agree with you if it wasn't taking me 3-5 days to get dev environment change controls approved that I've been getting approved in 2 hours or less for years. And to be clear, I am still working, but... this is DevRant... I'm ranting.

@EtherealRage ye absolutely. I actually face similar issue at work. Though it's not due to feature freeze but due to having to build 3 separate projects in a sequence to get a thing deployed on dev or higher (even more steps for stage and higher) so the idea of a functioning rapid development is somewhat of a dream unfulfilled for me :(