|
Regular review, and long design cycles. Lots of dogfooding by other developers. All of which is expensive.
Also, actually having a documentation and technical writing team working *with* the development team helps both parties make better stuff.
And then in terms of implementation I think they had an eye toward creating a "reference implementation" from the jump so there was some feeling that your code was going to be looked over by the public to keep people honest.
This is all just feels and vibes I got working from working on .NET and Visual Studio teams at Microsoft at points, nothing concrete.
But I will say this: Microsoft threw a ton of money at implementing the .NET BCL precisely because it was public facing. I don't know how public facing and broadly distributed the Frostbite editor source code is, but I do know EA is a big company and *can* produce clean code if they want to. It just costs more in terms of time (and thus money) - and trust me when I say that it's a hassle to have to code to standards that such necessarily requires - as well it should be since it's almost always harder to do the Right Thing(TM)
Real programmers use butterflies
|
|
|
|
|
I guess you nailed it.
It's possible, but it must be a real additional effort (as in a lot more time and money).
I guess I will have to suck it up, and contribute as much as I could to reduce complexity when I can... 
|
|
|
|
|
Maybe look at it this way? there's a sort of knack to this sort of forensic(ish) code analysis and it's valuable as all heck. This is an opportunity to get some practice at it and hone the ability.
Plus I've found that when I'm looking at Other People's Code(TM) it doesn't click until I understand their thought process. Once I do, I can get through code that would curl your hair.
My point is, you'll get through this mess, and be better for it.
Also, I'd add - I wouldn't try too hard to kill complexity - not that this isn't valuable. It's just that if you have to make the choice, there's more value in being able to continue the code using the model you were handed, if you can. Otherwise you're looking at a rewrite sooner than you otherwise would. Just my experience.
Real programmers use butterflies
|
|
|
|
|
Writing good code is a bloody pain. By which I mean that it is easy to understand what it wants to achieve, easy to find stuff where you expect it to be, and relatively easy to expand. No matter which pattern I use I always end up with a mess. 
Like with MVVM pattern, which seems to me to be only a pattern for splitting up the GUI in separate code snippets. It does that job very well, but that's about all you get from that. I have yet to find a pattern that helps me split up code into sections so that I don't have to revisit/reorganize at a later stage. Any thoughts or tips?
|
|
|
|
|
In C#/.NET I've found the use of partial classes to be fantastic for that.
For example, I'll have
MyList.IEnumerable.cs
MyList.ICollection.cs
MyList.IList.cs
And each file implements the named interface.
In C++ your options are ... messier. There's no way to split code up in C++ that I know of that doesn't add to complexity.
Real programmers use butterflies
|
|
|
|
|
Don't C++ allow implementation of multiple abstract classes?
|
|
|
|
|
Yes, but multiple inheritance comes with its own complexities. I wouldn't recommend it if your goal is to reduce complexity. This is triply true when templates are also involved.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: But I will say this: Microsoft threw a ton of money at implementing the .NET BCL precisely because it was public facing.
This is the key point. Friends who worked in the gaming industry mostly burned out due to the insane time-to-market "schedules". The entire point was to get the programs working so they could be published, and it didn't matter how programs worked as long as they worked.
Once a version was published, and sometimes before a version was published, it was on to the next version. There was no time to fix the errors of rushed coding unless something conflicted with something else in the next version.
Sure, this happens in other industries, but gaming is IMO the poster child for propagating and maintaining bad code.
|
|
|
|
|
That makes total sense to me. I mean, not that it works that way, but that gaming would be the one to do it.
The pressure to market is just overwhelming with games. It's a constant race against competitors, against newer hardware, against major shopping holidays - it's ridiculous.
I don't think there's a way to fix the code without fixing the above.
Real programmers use butterflies
|
|
|
|
|
nah, they cold like hell, get the game released and move on to another job.
I deal with it every day. If I could get chuckleheads to follow the design concept, but no, no one wants to hurt anyone's feelings. I deal with so much $hit code every day, some days I think my head is going to explode.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Super Lloyd wrote: How does one push back against the growing complexity?
If I may venture an opinion: sometimes you don’t. Sometimes that complexity reflects what I call “battle-scarred code”. Old code that has seen many battles is rarely clean but it contains that protection against a divide by 0, and can handle that weird situation we encountered 5 years ago and so on.
Really great companies, like Microsoft, might also have someone like Raymond Chen to maintain some kind of oral history project but in most places you just have to find yourself all the good stories hidden inside the code. And the bad ones too.
Anyway, I learned to respect the battle-scarred code.
Mircea
modified 29-Jul-21 10:16am.
|
|
|
|
|
I can second this.
Although as far Microsoft, having worked there, you're lucky when you can find history on some of their older but very much used components. There are functions used in oleaut32.dll routinely that I swear nobody at microsoft actually knows how they work, or maybe even how to call them properly anymore.
Real programmers use butterflies
|
|
|
|
|
Having worked elsewhere, Microsoft seems like a paragon of software quality. I’m sure the view from inside is different but those who like sausages should not ask what’s inside 
Mircea
|
|
|
|
|
Their departments are semi-autonomous. Their quality kind of depends on the department, but in general they follow the same basic practices, some just better than others. When they do it well, they are really good. They do regression, stress testing, they instrument for code coverage. They have bug counts and charts of counts and goals on the hallways outside of developers quarters. They really do put an emphasis on it. It's why I am so not happy with their windows updates. They can do better. Something happened since I left. 
Real programmers use butterflies
|
|
|
|
|
Quote: Something happened since I left
You left, obviously! 
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I thought that would have improved things. 
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: There are functions used in oleaut32.dll routinely that I swear nobody at microsoft actually knows how they work, or maybe even how to call them properly anymore.
COM is probably one of the best understood technologies at Microsoft. Many of the old COM/OLE guys are still around. Although Don Box[^] left two months ago.
The only API that I know of that might have been lost is the DirectUI code. When the team was dissolved apparently some of the source code disappeared. There was like 1 guy in building 88 with some DirectUI header files last I heard.
|
|
|
|
|
LOL
oleaut32.dll has a few functions for mangling typelibs that nobody uses anymore, but I had to emulate at one point. I never finished that part because nobody at MS could tell me what they did. I even contacted people involved in the Windows OS team when I was on it.
Real programmers use butterflies
|
|
|
|
|
Hmmmm,
honey the codewitch wrote: I even contacted people involved in the Windows OS team
I am pretty sure that the mangling is controlled by the interface definition language[^] so you probably should have asked someone on the compiler team instead.
There use to be some non-public MIDL reserved keywords on our internal build tools. I'm not sure if that's still a thing.
|
|
|
|
|
The IDL facilities use the typelib facilities i'm talking about. The compiler team did not create oleaut32.dll
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: The IDL facilities use the typelib facilities i'm talking about. The compiler team did not create oleaut32.dll
No, we are in a grey area here... oleaut32 has it's origins in VB5. I believe it was distributed with the VB5/VB6 runtime prior to Windows XP SP1.
What time frame are you referring to? Was this back when you worked at the company?
|
|
|
|
|
It was old by the time I was working on the Windows team in about 2001.
oleaut32 is a system DLL - i could have sworn it predated VB5 because of OLE automation which predates it, but my memory isn't so reliable these days.
oleaut32.dll provides system implementations of things like IDispatch and ITypeLib. It's basically the guts that make Automation work inside of what is now known as ActiveX** but prior to that was simply called OLE (object linking and embedding)
** I'm simplifying a little bit. OLE and ActiveX both exist, and ActiveX was sort of intended as OLE pared down for web downloads at first but then it became the de facto way to develop new components.
Real programmers use butterflies
|
|
|
|
|
|
Mircea Neacsu wrote: someone like Raymond Chen
I remember some Microsoft blog video some years ago, and cant remember if was talking to him, that essential majority of the .net documentation (at least 2005 - 2015 maybe) was passed through this one person, hence provided great consistency across the documentation.
As to Frostbite, I wonder how much gaming industry project to project rehire cycle has an impact, and the get it out the door.
If you have somthing like World of Warcraft, where new players coming in over the years, then fixing "old" parts are relevant to user support.
Also go read Object-oriented programming is dead. Wait, really? posted in articles the other day, might be relevant to how people thought they needed to program the system over the years vs reality of programming it.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
