Do you guys still see the relevance of using code freezing instead of just properly managing versions, repositories and branches in a cyclical manner, given how advanced software practices and tools are supposed to be?

To give some context, the company I work for uses the complete trash project management practice of asking teams to work on a sprint basis, but there is still a quarterly milestone and code freeze to commit to and it's where shit hits the fan.

Development teams rush features at the end of the quarter because they had to commit at the very least to a 6 months in advance planning (lol?) and turns out, not being able to design and investigate properly a feature combined with inflexible timelines has high chances to fail. So in the end, features are half-assed and QA has barely any time to test it out thoroughly. Anyways, by the time QA raises some concerns about a few major bugs, it's already code freeze time. But it's cool, we will just include these bug fixes and some new features in the following patches. Some real good symver, mate!

Of course, it sure does not help that teams stopped using submodules because git is too hard apparently, so we are stuck with +10Gb piece of trash monolithic repository and it's hell to manage, especially when fuckfaces merges untested code on the main branches. I can't blame Devops for ragequitting if they do.

To me, it's just some management bullshit and the whole process, IMO, belongs to fucking trash along with a few project managers... but I could always be wrong given my limited insight.

Anyways, I just wanted to discuss this subject because so far I cannot see code freezing being anything else than an outdated waterfall practice to appease investors and high management on timelines.

Not really a code freeze period, but at my current project they use locked dependency files which can very easily refer to 2-year old custom packages if the importing package is not updated regularly.
Ir drives me mad when a 2-line code change results in 3+ packages LCM work with debugging and fixing errors in UT and sometimes E2E...
So for the love of god: if you have any influence in how your pipelines run and how your codebase is managed, try and get some weekly build/deploy (depending on your release intervals) which updates and tests EVERYTHING

I couldn't imagine having to work with code freeze periods o.o

Submodules are the worst.

No discussion. Its messy. Its shitty. Its abused for things I don't want to mention without severe pain suppressors.

What most people struggle with - and what this rant sounds much too me - is properly designing and sticking to it architecture.

10 gb plus... This sounds much unhealthy. Would be curious to know how this number came to be and what exactly we're talking about, cause if its a pure project with solely the code (e.g. no embedded dependencies, no "half assed integrated libraries" [submodules])... Then that is a real morbid obese monolith.

Not saying it isn't possible.

After all, Microsoft has 300 GiB of data:

https://devblogs.microsoft.com/bhar...

... And invented a filesystem to handle that.

But MS does in my opinion something horrible wrong: API compatibility at all costs.

Which is utter madness but loved by enterprise software as you can still run Win98 software on 10 (at least in theory).

Utter madness as this software will exhibit all kinds of pestulence. Security flaws, performance flaws, probably not running as intended... After all, that software was designed at a point of time in the past - for the hardware, software and mindset at that point of time.

Which is why I really hate enterprise software. Most of the time its a stitched together frankenstein of many decades.

Just to keep the Windows fanboys at bay:
https://engineering.skroutz.gr/blog...

Enterprise software means everything with a life span over 5 years. Yep, that means Linux, too.

To finish my monologue: Version management and release management are two different things that should work well together.

Release management aka "when to freeze for new features, what does a release contain, what different types of releases exist (milestone, release candidate, ...) - while version management is more the question of what a version number represents like SemVer.

code freezes are a great tool.

Mostly to stop management from never finishing a proper release.

Proper release as in "these features should be in the next release" as the release was planned.

Not baked... Planned.

Simply put: Plan a release, mediate with management what they want, close the bag, whip the devs to make the release, gaffa tape management to stop wishing for new features in the currently planned release, when all features are done by dev: Code freeze and give it to QA.

Then restart the cycle of hatred.

2 week sprints, code freeze measures, and major product releases every quarter aren't uncommon. In fact, it has become pretty common. Unless you can really do daily or (at least) weekly releases, this is what you could settle for

I think the problem lies in

1. Not planning the grooming, designing, and building the features and capabilities you want enough ahead of time or on time
2. Committing code at the end of the quarter just to make your changes be included in the release. We had done such mistakes in the past as well. We enforced a practice that no major commit/change is introduced in the last 2 weeks unless you liaise with QE and get their (conditional) signoff
3. Forcing Engineers to adhere to the release schedule. This is counter productive right from product to Engg, to QE, to RE, to Customers, and to whoever else involved here. If a feature/change can't be accomodated, it cannot be accomodated. No point in twisting arms and taking shortcuts. Be more realistic

4. Not learning from mistakes in the past. Why do Engineers rush their changes towards their end? Are they fucking sloppy? Were they allocated other work until then? Is the Development that hard to do that it takes too long a time to finish? Is the QE finding bugs late in the cycle? Do you have nightly tests that will test the quality day on day? Many questions should be raised and analysed. In fact, we could stop any Engineering work for a quarter and use this time to dissect the problems and get to the root causes
5. Someone who is not connected to Engineering (in any way) is given the authority to commit to deadlines and speak marketing bullshit in front of customers. They should be terminated right away

Don't agree with what you describe - but code freezes in isolation can make sense in some circumstances. We freeze over black Friday for example, as it lowers the risk of something horrendous breaking during our busiest trading period of the year. But there does have to be a reason for it.

@AlmondSauce yeah it was mostly a rant on a crappy company process I guess. I am sure code freezing, like any tool, has its purpose if used properly.

@asgs so everything gets rushed because higher management makes a push on the engineering teams to deliver something working to customers because promises were made 6-12 months ago by Sales team.

And the problem lies in there: fucking sales team, as usual, does not communicate properly with engineering and once they have an engagement in concrete, it is hard for engineering to manage. They have to commit to inflexible estimates at long term but RnD at long term is dicey at best.

QA gets the most fucked over because they have to rush test a feature in automation in a few weeks and bugs or design problems are not taken seriously until customers find them.