I wrote and maintained most of a (2d) video game library over the course of four years. Almost entirely by myself. I just looked, and it comes to something like 80000 lines of code.
So you're saying I was maintaining code that was ultimately enough for four full-time maintenance engineers while developing two games as lead, supporting other developers to put together nearly 100 games based on that library (I was also externally-facing support), AND designing and implementing the beginning of the next revision of the library)?
And people also raved about my support, to the point where it felt like I had a fan club. Maybe the bar is just that much higher in video game development; I'm certainly not even the most efficient developer I know.
I did refactor the code from time to time, though there were a lot of games based on this library by the end that I couldn't risk breaking, so I couldn't change the public API. Mostly I just wrote it to be solid the first time around. It was the fourth or fifth time I'd written a similar game library; after a while you get the hang of it, you know? Not to say there were never bugs, but they were (almost) always easy to find and fix, since the architecture was solid.
My only point really is that rules of thumb like the one about 20k lines of code per maintenance engineer can be off by an order of magnitude or more, if you've got the right code and the right developer. I'd estimate that no more than about 40% of my time at the end was taken up by maintenance, and it was probably more like 25%. And a lot of my "maintenance" time was spent fixing bugs in other developers' games that they just couldn't find, and that weren't in my code at all.
Working on other people's code has a much higher overhead. Before you can make any change, you have to understand how it interacts with the rest of it. It's not unrealistic to spend days studying it, then minutes changing it. Then you move on to yet another unfamiliar codebase - and by the time you get back to the first, months have passed, you've forgotten all about it, and other people have been changing it too so you need to relearn it.
This is why when I interview people who say they've been programming since they were 10, I don't really care - because the experience of working on your own code is radically different from working on an existing codebase.
Yeah, fixing other people's code takes longer, most of the time. I did frequently have to fix bugs in other people's game code, though I've done games long enough that usually I would know how to dig and find the issue pretty quickly.
It didn't typically take more than a day or two to find such bugs, even if the original developer (working on their own code) had tried to find it for weeks and had given up. I could always come in with fresh eyes, and I know most of the ways that people write games, good and bad. In one case I had their "intractable" bug fixed in less than a half hour, having never seen their code before.
So I think I'd probably still pass that interview question, though I'm not looking for a job right now. ;)
That's overly harsh. Having long-time programming experience does help, also in understanding other people's code faster. It's almost impossible to be programming since your 10th and never been confronted with other people's code in one way or another. Either through open source collaboration, reverse engineering, or even studying/improving example code.
(also it means that they are pretty fanatical programmers thus that they're self-motivated)
My only point really is that rules of thumb like the one about 20k lines of code per maintenance engineer can be off by an order of magnitude or more, if you've got the right code and the right developer.
Yes. Absolutely. That number applies to average code and there are obviously ways to push it out if a person cares (which you did, since it was your project and 4 years of your life were on the line). For example, unit tests add LoC but improve code health.
I didn't think to add in the LoC from tests...that's about another 8k lines, if that matters.
Game code is...notoriously hard to unit test. We had some functional (?) tests that would do complete screen renders and check the resulting bitmap against a "correct" result, though that was mostly for verifying the code worked correctly on all target platforms, and some unit tests for classes like the string class that were relatively easy to create useful tests for, but far from complete coverage. Most HN developers would probably consider the coverage pathetic, I'd guess, and I rarely even ran the tests (they were mostly for QA).
I've actually never seen anyone create unit tests for actual game code. I've heard about it being done, but it's a rare exception rather than the rule. The religion of "Test First" hasn't really caught on in game development.
Most of the "business logic" (so to speak) changes so fast as you're developing a game it that creating unit tests to verify it doesn't make sense. Also, a lot of the behaviors are "fuzzy" or visual, and unit tests can't tell you if the results feel right -- for that you just have to play the game. Some of the more structural parts of a game's code could COULD stand to be tested, but in general it's not considered to be valuable enough to offset the cost.
So you're saying I was maintaining code that was ultimately enough for four full-time maintenance engineers while developing two games as lead, supporting other developers to put together nearly 100 games based on that library (I was also externally-facing support), AND designing and implementing the beginning of the next revision of the library)?
And people also raved about my support, to the point where it felt like I had a fan club. Maybe the bar is just that much higher in video game development; I'm certainly not even the most efficient developer I know.
I did refactor the code from time to time, though there were a lot of games based on this library by the end that I couldn't risk breaking, so I couldn't change the public API. Mostly I just wrote it to be solid the first time around. It was the fourth or fifth time I'd written a similar game library; after a while you get the hang of it, you know? Not to say there were never bugs, but they were (almost) always easy to find and fix, since the architecture was solid.
My only point really is that rules of thumb like the one about 20k lines of code per maintenance engineer can be off by an order of magnitude or more, if you've got the right code and the right developer. I'd estimate that no more than about 40% of my time at the end was taken up by maintenance, and it was probably more like 25%. And a lot of my "maintenance" time was spent fixing bugs in other developers' games that they just couldn't find, and that weren't in my code at all.