Patch delay discussion and news

[draconus]

Wow, so a special thread was created for people to vent on missing update?

There was a plan for an update and ED told us the planned date.

Testing revealed signifact enough bugs so the update got delayed.

Everything works as intended - what's the problem?

Can they not announce updates? No.

Can they foresee problems? No.

Can they push bad update? No.

But they can do hotfixes! Some showstoppers like F-15E radar should be hotfixed asap.

[Badger1-1]

Just now, draconus said:

Wow, so a special thread was created for people to vent on missing update?

There was a plan for an update and ED told us the planned date.

Testing revealed signifact enough bugs so the update got delayed.

Everything works as intended - what's the problem?

Can they not announce updates? No.

Can they foresee problems? No.

Can they push bad update? No.

But they can do hotfixes! Some showstoppers like F-15E radar should be hotfixed asap.

F15E Radar, if you saw the reddit post by the guy who made it, is intentional from his side as a fail safe, no hotfix until hes paid by RB. 

[draconus]

8 minutes ago, Badger1-1 said:

F15E Radar, if you saw the reddit post by the guy who made it, is intentional from his side as a fail safe, no hotfix until hes paid by RB. 

No, it doesn't matter who and why did it. I know it and how to workaround, ED knows how to fix already.

[Badger1-1]

proofs my point of more smaller update cyles..

[Blazkovitch]

5 minutes ago, Badger1-1 said:

proofs my point of more smaller update cyles..

How would that help?

[bueno]

6 minutes ago, Badger1-1 said:

proofs my point of more smaller update cyles..

smaller cycle means a lot. There is good and bad :

- you have frequent update but less content per update
- you release ma LOT so you stress a LOT the QA team and QA cycle are shorter too.
- more complex to follow a roadmap on 12 months and make announcement or you need to introduce some notion like the PI planning...

nothing is black or white. They have to make choice and we will always find unhappy people/customers...it's like this.

[draconus]

8 minutes ago, Badger1-1 said:

proofs my point of more smaller update cyles..

Already explained - no longer possible with current DCS size.

[cfrag]

Since @BIGNEWY was kind enough mentioned that their upcoming patch is BIG (a MOAR?), we can happily guess (without any actual knowledge!) what such a big release may  include:

Gobsmackers
- Hook
- 'Stan
- Kola "Winter Soldier" 
- SupCarrier changes 
- FC 2024 
- Maybe even some bug fixes to some great modules, e.g.
    - Mudhen Radar 
    - Kiowa crew 
    
"Talked About" 
- Sinai first patch (one year worth of updates, may require map tech)
- Iraq

Even More Highly Speculative
- some new map tech
- some new weather tech
- Airport AI
- Vulkan
- MT for servers 
- new campaigns  
- New Campaign Engine (included just for laughs, I know)
- Persistence (again, just for laughs)

or, plainly, a "DCS 3++"? That list above is indeed much too big to handle for anyone who strives to preserve their sanity.

So, I agree with @YoYo's assessment that ED's products have grown too large to be managed in 'Big Block' releases. I'm thinking that they could investigate a multi-track release train, one for technology/bugfixes (the "world" track) on a 4-week schedule, and a "feature" track that has a distinct schedule that does not coincide with the world track. So if a feature has dependencies on a world feature, it will always come at least a week after a world release that enables it.  

No matter what, I'm happy to wait for the new patch, and I merely wish that ED would simply communicate more, and better include their Forums so dinosaurs like I who don't frequent discord, Facebook or Twitter can also be up to date.

Good luck and Godspeed, ED - and let's hear a bit more about what you got in store for us  

Edited July 5, 2024 by cfrag

[cfrag]

1 hour ago, bueno said:

It's a software department. So they develop in Agile.

That's IMHO an unwarranted assertion, unless you can point to some tangible proof. A software company heralding back to the 90's of last millennia is unlikely to have gone Agile, plus in my (some 30 years of large-scale project management) experience, the advantages of Agile are massively oversold by consultants trying to sell some "methodology of the year".  There are advantages to Agile if you are start-up, and your teams and release train can cover the entire product. That is highly unlikely in what we see in ED's modus operandi today, and my guess is that they employ a development methodology that they deem best fitting for their current product portfolio.

1 hour ago, bueno said:

But whatever. I'm piloting a team of Dev too and trust me : it's BETTER to delay than to deliver a version with bugs, regression and side effects. 

Yes, and above only applies if you develop large monolithic blocks. That's not the Agile way, as you should know, so you are somewhat contradicting yourself. "Release early, release often" is an Agile Motto, and you only pull from your Backlog what can be done in 2 Sprints. The Definition Of Done usually includes "tested" (unless your Scrum Master loves living on the edge), and in your Sprint Reviews you'll note when something isn't up to snuff and shove it into the next sprint until it's really done. The idea of Agile is exactly that you can rapidly release stuff without show-stopping bugs. But yeah, I'm the first one to agree that "Agile" is just an oversold fad that doesn't work will in large (i.e. non-startup) projects, no matter what that McKinsey guy sold the CEO.

Edited July 5, 2024 by cfrag

[Blazkovitch]

16 minutes ago, cfrag said:

and my guess is that they employ a development methodology that they deem best fitting for their current product portfolio.

XP!

[bueno]

I m not sure they are in Agile...but I imagine...Moreover, if they are, I ignore the lenght of their sprint. And yes the Dod Include test for sure. Honnestly I thnik they are in agile or adapt Agile methodo to theuir process. I cannot imagine that they dev in waterfall.

In Agile you release waht is ready (some tested and bug free). It can be fix or features.

[cfrag]

10 minutes ago, bueno said:

I cannot imagine that they dev in waterfall.

Don't knock Waterfall, it's been serving us (Civilization) great since way before the Pyramids. Methodologies are tools that multiply the abilities of the PM/team, the do not enable. And Waterfall, for all it's 'primitivity' serves exceedingly well, especially if you add some lessons learned from newer Methodologies like RUP, SAFE etc. Waterfall with Kanban, Daily Standups and some DoD can be orders of magnitude more effective than restructuring your organization for Agile, and then lose all control over your release train because unguided Agile-enabled teams all fumble their releases. 

15 minutes ago, bueno said:

In Agile you release waht is ready (some tested and bug free).

Which I believe is the best argument against what ED is practicing. They did not release what works, they postponed what appears to be a monolith repeatedly. Then again, I have no knowledge of how ED develop their products, I'm merely guessing here.

[Baldrick33]

17 hours ago, =Mac= said:

As I see it (as an ex-IT guy), the ED coding staff is too small, improperly managed, and QA is missing (which dumps QA on us.) I was a developer back when the IBM 360/370 was THE thing. Nothing I ever released had coding flaws in it. A customer would want more things added but that usually brought about a weekend addition followed by a six week QA check.

Having worked in IT for over 30 years in a Corporate environment and having been behind the scenes on several Alpha and Beta simulation games development (not DCS for the avoidance of doubt) the games development world couldn't seem more different. If customers were prepared to pay business rates for software and wait for near bug free (fully tested for months on all variations of hardware) releases then maybe developers could increase the coding staff and employ corporate development methodologies but I don't see either happening.

Also your IBM 360/370 wasn't connected to a zillion different home computers with full admin rights devolved to your users!

[Grennymaster]

vor 2 Stunden schrieb draconus:

Wow, so a special thread was created for people to vent on missing update?

There was a plan for an update and ED told us the planned date.

Testing revealed signifact enough bugs so the update got delayed.

Everything works as intended - what's the problem?

Can they not announce updates? No.

Can they foresee problems? No.

Can they push bad update? No.

But they can do hotfixes! Some showstoppers like F-15E radar should be hotfixed asap.

yeah, for many folks it seems that planned means guarantied.....

what also seem to often not is understaned is, exactly what Baldrick 33 wrote. There are zillion of PC´s using the software. how should you test that so it could nothing bad happen.

[Hotdognz]

1 hour ago, cfrag said:

Since @BIGNEWY was kind enough mentioned that their upcoming patch is BIG (a MOAR?), we can happily guess (without any actual knowledge!) what such a big release may  include:

Gobsmackers
- Hook
- 'Stan
- Kola "Winter Soldier" 
- SupCarrier changes 
- FC 2024 
- Maybe even some bug fixes to some great modules, e.g.
    - Mudhen Radar 
    - Kiowa crew 
    
"Talked About" 
- Sinai first patch (one year worth of updates, may require map tech)
- Iraq

Even More Highly Speculative
- some new map tech
- some new weather tech
- Airport AI
- Vulkan
- MT for servers 
- new campaigns  
- New Campaign Engine (included just for laughs, I know)
- Persistence (again, just for laughs)

or, plainly, a "DCS 3++"? That list above is indeed much too big to handle for anyone who strives to preserve their sanity.

So, I agree with @YoYo's assessment that ED's products have grown too large to be managed in 'Big Block' releases. I'm thinking that they could investigate a multi-track release train, one for technology/bugfixes (the "world" track) on a 4-week schedule, and a "feature" track that has a distinct schedule that does not coincide with the world track. So if a feature has dependencies on a world feature, it will always come at least a week after a world release that enables it.  

No matter what, I'm happy to wait for the new patch, and I merely wish that ED would simply communicate more, and better include their Forums so dinosaurs like I who don't frequent discord, Facebook or Twitter can also be up to date.

Good luck and Godspeed, ED - and let's hear a bit more about what you got in store for us  

 

Your speaking in common-sense terms, stop it

[Blackhawk NC]

This will be possibly the biggest update in DCS history..........But i bet there won't be anything in there for REDFOR.......

[Gunfreak]

Just now, Blackhawk NC said:

This will be possibly the biggest update in DCS history..........But i bet there won't be anything in there for REDFOR.......

New cup holder in the KA50

[SmirkingGerbil]

All the new users advising that patches should be smaller, faster, and on a shorter schedule - That, is how we got here, no longer feasible.

Basically 9 pages of:

1.) Those who have developed software, or worked on large complex projects - "Thanks for the update, would rather released clean and no show stoppers."

2.) Those that see anyone in the above group as "Shills and Fanboi's for DCS."

I am in the first group. Thanks ED!!

[Dragon1-1]

3 hours ago, Blazkovitch said:

How would you prove that the game does not crash after 01/01/2025? It is a showstopper, right?

It's not. They have until 01/01/2025 to notice the time bomb (because if it's anything that specific, it won't be an accident) and remove it. Hence, it does not meet the definition of showstopper. Generally, outside the circumstances such as the infamous millennium bug, or the upcoming Unix time rollover, computer programs act the same no matter on which date they're run, unless they have been programmed to check the timestamp. So, while it's difficult to "prove", it's a pretty unlikely issue in any case. A showstopper is generally something that breaks the game for a lot of people, so it's reasonable to expect QA to spot it.

Computer programs are not magic, though it might seem that way to uninitiated. They are, in essence, very complex mathematical expressions, written by humans, and are perfectly deterministic. In civil engineering, for example, a bug would be called "human error" and the originator likely persecuted after, say, the bridge he built collapsed. And just like it is possible to design a bridge that doesn't spontaneously collapse (how would you prove it won't collapse after 01/01/2025? Well, there are entire companies making tools for that), it is, theoretically, possible to design a program, even a complex one, without any bugs in it. It's just harder and more expensive, and not helped by the thinking that permeates the consumer programming community, that treats the presence of unintended behavior as a law of nature. Go into embedded programming, especially serious stuff like trains or spacecraft engineering (outside a certain well known company, that is), and you'll see that's exactly what they do. If cars were designed like computer programs are, well, see Tesla, especially early on.

[Ironhand]

Patch delayed again? Guess I’ll just go and fly. Beats hell out of not flying for 3 or 4 days while the patch downloads.

[stburr91]

1 hour ago, SmirkingGerbil said:

All the new users advising that patches should be smaller, faster, and on a shorter schedule - That, is how we got here, no longer feasible.

Basically 9 pages of:

1.) Those who have developed software, or worked on large complex projects - "Thanks for the update, would rather released clean and no show stoppers."

2.) Those that see anyone in the above group as "Shills and Fanboi's for DCS."

I am in the first group. Thanks ED!!

 

There is a third group, people who understand that updating a game like DCS is very complex, takes time, and testing will reveal bugs. However, these people are saying, go through your process, get the update ready, then announce a release date, so we can avoid all these delays.

 

All of these delays, too many projects being in EA, slowing progress to a crawl, and a dispute with a 3rd party developer, are all wearing the customers patience very thin. This doesn't seem like a sustainable path for ED.  

[Blazkovitch]

1 hour ago, Dragon1-1 said:

It's not. They have until 01/01/2025 to notice the time bomb (because if it's anything that specific, it won't be an accident) and remove it. 

3rd party modules are provided in a binary form as far as I understand. I wouldn't expect anyone to read asembly in order to find bugs. And we can clearly see that at least one third party is not doing any code reviews.

1 hour ago, Dragon1-1 said:

In civil engineering, for example, a bug would be called "human error" and the originator likely persecuted after, say, the bridge he built collapsed. 

This is mainly because humans have been constructings things for the last... oh, several thousand years while computing is really a matter of the last 80 years or so? And building a bridge is much easier than understanding what computer does because in civili engineering everything can be thoroughly simulated and the laws of physics generally do not change on a daily basis.

1 hour ago, Dragon1-1 said:

it is, theoretically, possible to design a program, even a complex one, without any bugs in it. It's just harder and more expensive, 

Only if you can provide a specification that covers every aspect of the program and is generally considered extremely expensive. Good luck with doing that for a game.

1 hour ago, Dragon1-1 said:

Go into embedded programming, especially serious stuff like trains or spacecraft engineering (outside a certain well known company, that is), and you'll see that's exactly what they do. If cars were designed like computer programs are, well, see Tesla, especially early on.

And clearly there are no bugs in spacecrafts (1201 and 1202 alarms in AGC), issues caused by speculative aspects of CPUs, very subtle bugs in multithreaded programs, bugs in CPU microcode, etc, etc. 

[Steel Jaw]

Oh my, the entitled drama....

[FalcoGer]

Writing some code takes some amount of time. Whatever amount of testing you are planning seems to always be at least 50% off the mark. Usually testing, fixing and retesting takes about as long as it takes to write the feature or project in the first place.

I do agree though that code that does not affect other code changes should be written such that it can be tested and merged in independently using some form of version control software. And then when patch day comes, you just release what is ready, instead of what seems to be happening now, where a single problem or two hold up the entire process, and the rest of the team might even have to twiddle their thumbs because anything new they do might break things even more.

That is why version control software exists to begin with. To incrementally put in changes, concurrently work on different parts of the project by different developers, to reference commits and have reasons behind each change in the form of commit messages, to have accountability, to have code reviews, to compare different versions and why things might work differently now than before a change was made, and to have something to roll back to in case the poop hits the ventilator.

Edited July 5, 2024 by FalcoGer

[hawk4me]

@BIGNEWY Has the staff ever thought about sharing some of the more interesting bugs found when things like this happen? More like a fun how the crap did that happen kind of thing. When you guys mention game breaking bug's i'm thinking of planes flying straight off the ground then exploding on impact. Or maybe you fly faster than mach 2 and your hair is on fire with cockpit filled with smoke kinda thing lol.