How do you maintain code quality / complexity?
-
As I am starting my new job at EA, working on the Frostbite Editor, which is easily a 1000 man years job if I were to hazard guess... The codebase is very large! And the parts I am working on are very messy... Trying to study one little bit of functionality... the code ping pong between many different classes which all work on the same data at the same time, it's very challenging to grasping it all. One might call it some sort of spaghetti code. Now.. it might seems inevitable on large project with large team... But, at the risk of being blind folded by fanboyism, I think Microsoft.NET API code looks quite neat and simple. And this is a large project API too, 20 years in the making! By a large corporation! So.. how did they do it? How does one push back against the growing complexity?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
As I am starting my new job at EA, working on the Frostbite Editor, which is easily a 1000 man years job if I were to hazard guess... The codebase is very large! And the parts I am working on are very messy... Trying to study one little bit of functionality... the code ping pong between many different classes which all work on the same data at the same time, it's very challenging to grasping it all. One might call it some sort of spaghetti code. Now.. it might seems inevitable on large project with large team... But, at the risk of being blind folded by fanboyism, I think Microsoft.NET API code looks quite neat and simple. And this is a large project API too, 20 years in the making! By a large corporation! So.. how did they do it? How does one push back against the growing complexity?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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
-
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... :)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
As I am starting my new job at EA, working on the Frostbite Editor, which is easily a 1000 man years job if I were to hazard guess... The codebase is very large! And the parts I am working on are very messy... Trying to study one little bit of functionality... the code ping pong between many different classes which all work on the same data at the same time, it's very challenging to grasping it all. One might call it some sort of spaghetti code. Now.. it might seems inevitable on large project with large team... But, at the risk of being blind folded by fanboyism, I think Microsoft.NET API code looks quite neat and simple. And this is a large project API too, 20 years in the making! By a large corporation! So.. how did they do it? How does one push back against the growing complexity?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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
-
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... :)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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
-
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
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
-
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 :laugh:
Mircea
-
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 :laugh:
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. :mad:
Real programmers use butterflies
-
As I am starting my new job at EA, working on the Frostbite Editor, which is easily a 1000 man years job if I were to hazard guess... The codebase is very large! And the parts I am working on are very messy... Trying to study one little bit of functionality... the code ping pong between many different classes which all work on the same data at the same time, it's very challenging to grasping it all. One might call it some sort of spaghetti code. Now.. it might seems inevitable on large project with large team... But, at the risk of being blind folded by fanboyism, I think Microsoft.NET API code looks quite neat and simple. And this is a large project API too, 20 years in the making! By a large corporation! So.. how did they do it? How does one push back against the growing complexity?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Maybe you can use one of these analysis tools: code-visualization-and-analysis-tools[^]
-
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
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.
-
As I am starting my new job at EA, working on the Frostbite Editor, which is easily a 1000 man years job if I were to hazard guess... The codebase is very large! And the parts I am working on are very messy... Trying to study one little bit of functionality... the code ping pong between many different classes which all work on the same data at the same time, it's very challenging to grasping it all. One might call it some sort of spaghetti code. Now.. it might seems inevitable on large project with large team... But, at the risk of being blind folded by fanboyism, I think Microsoft.NET API code looks quite neat and simple. And this is a large project API too, 20 years in the making! By a large corporation! So.. how did they do it? How does one push back against the growing complexity?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Working on several generations of the same project for 25 years almost I see that there is no straightforward solution for this. Setting up code standard does not help, code review does not help... There is no way to 'clean' an old and complex code but to rewrite it from ground up - it will probably cost more in time than the original investment combined over years and will left you with a buggy code to test from zero...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
As I am starting my new job at EA, working on the Frostbite Editor, which is easily a 1000 man years job if I were to hazard guess... The codebase is very large! And the parts I am working on are very messy... Trying to study one little bit of functionality... the code ping pong between many different classes which all work on the same data at the same time, it's very challenging to grasping it all. One might call it some sort of spaghetti code. Now.. it might seems inevitable on large project with large team... But, at the risk of being blind folded by fanboyism, I think Microsoft.NET API code looks quite neat and simple. And this is a large project API too, 20 years in the making! By a large corporation! So.. how did they do it? How does one push back against the growing complexity?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
How does one push back against the growing complexity?
In your situation, I don't think you can push back. I don't think you want to push back. The code base is mature, and tested many, many times. You can't change it from the ground up, if that is what you are thinking; not for Frostbite, I would think. I think your best bet is to maintain existing code without refactoring too much, and adding new code in a proper, well organized and scalable fashion, the best you can. Remember, any code you maintain, that has been tested and is working in Production, and you refactor or change it, you have now added potential bugs to it. The less you refactor or change of existing code, the better.
-
As I am starting my new job at EA, working on the Frostbite Editor, which is easily a 1000 man years job if I were to hazard guess... The codebase is very large! And the parts I am working on are very messy... Trying to study one little bit of functionality... the code ping pong between many different classes which all work on the same data at the same time, it's very challenging to grasping it all. One might call it some sort of spaghetti code. Now.. it might seems inevitable on large project with large team... But, at the risk of being blind folded by fanboyism, I think Microsoft.NET API code looks quite neat and simple. And this is a large project API too, 20 years in the making! By a large corporation! So.. how did they do it? How does one push back against the growing complexity?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
the parts I am working on are very messy...
Free tip : If I were you, I'd be very careful with such statements on the internet about your current job, especially since you mentioned your employer's name and even the projects you are working on. Be unspecific, Loungers know where you work :-)
-
Super Lloyd wrote:
How does one push back against the growing complexity?
In your situation, I don't think you can push back. I don't think you want to push back. The code base is mature, and tested many, many times. You can't change it from the ground up, if that is what you are thinking; not for Frostbite, I would think. I think your best bet is to maintain existing code without refactoring too much, and adding new code in a proper, well organized and scalable fashion, the best you can. Remember, any code you maintain, that has been tested and is working in Production, and you refactor or change it, you have now added potential bugs to it. The less you refactor or change of existing code, the better.
This is very wise and I second all of it.
-
As I am starting my new job at EA, working on the Frostbite Editor, which is easily a 1000 man years job if I were to hazard guess... The codebase is very large! And the parts I am working on are very messy... Trying to study one little bit of functionality... the code ping pong between many different classes which all work on the same data at the same time, it's very challenging to grasping it all. One might call it some sort of spaghetti code. Now.. it might seems inevitable on large project with large team... But, at the risk of being blind folded by fanboyism, I think Microsoft.NET API code looks quite neat and simple. And this is a large project API too, 20 years in the making! By a large corporation! So.. how did they do it? How does one push back against the growing complexity?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Large codebases inevitably get convoluted, over decades, especially if requirements evolve a lot, as they might do in a game editor. I would discuss the complexity within the team. Maybe you can identify a module that is suitable for refactoring, and suggest something. If your team responds with a shrug then that is an answer too. And, I wouldnt worry too much about your boss givning you a hard time for mentioning names. Who wants to work in a place where paranoia is necessary anyway?
"If we don't change direction, we'll end up where we're going"
-
As I am starting my new job at EA, working on the Frostbite Editor, which is easily a 1000 man years job if I were to hazard guess... The codebase is very large! And the parts I am working on are very messy... Trying to study one little bit of functionality... the code ping pong between many different classes which all work on the same data at the same time, it's very challenging to grasping it all. One might call it some sort of spaghetti code. Now.. it might seems inevitable on large project with large team... But, at the risk of being blind folded by fanboyism, I think Microsoft.NET API code looks quite neat and simple. And this is a large project API too, 20 years in the making! By a large corporation! So.. how did they do it? How does one push back against the growing complexity?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I would join with my esteemed colleague, Rage, in cautioning you about public disclosure of opinions and information about an identified company where you work; 1) this could be perceived as unauthorized disclosure of privileged private information. 2) because you are a newcomer to a large company, and to working on a complex code-base developed over years, the things you say could be interpreted by others at the company as grandstanding, as presumptuous, as carping. 3) given you acknowledge you are at a beginner/journeyman level understanding of the code-base, have you earned the credibility to make such comments ? Speaking as a friend, I strongly encourage you to consider the risks of such disclosure. If you were laid-off for cause ... unauthorized disclosure ... imagine how that might damage your future employability.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
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
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. :sigh: 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?
-
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. :sigh: 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
-
As I am starting my new job at EA, working on the Frostbite Editor, which is easily a 1000 man years job if I were to hazard guess... The codebase is very large! And the parts I am working on are very messy... Trying to study one little bit of functionality... the code ping pong between many different classes which all work on the same data at the same time, it's very challenging to grasping it all. One might call it some sort of spaghetti code. Now.. it might seems inevitable on large project with large team... But, at the risk of being blind folded by fanboyism, I think Microsoft.NET API code looks quite neat and simple. And this is a large project API too, 20 years in the making! By a large corporation! So.. how did they do it? How does one push back against the growing complexity?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Best resolved as follows: 1 - Ctl-A 2 - DEL
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
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
