Hacker News Reader

> Second, if someone in a big company generates 250 LoC/day reliably over years, it doesn't always mean that person is a great programmer; it could mean that, or it could mean that he's always taking the fun, "green field" projects and passing the legacy maintenance (on which 10 LoC/day is a typical clip) to others.

This is what I call the Dirty Little Secret of Corporate IT shops: The mediocre programmers spin a story and slag off others to get the jobs developing new systems or rewrites in new technology to pad their CV; the programmers with aptitude end up in maintenance roles digging deep through the said code to fix all the bugs afterwards and make that software usable, while the mediocre programmers who wrote it are already in their next jobs doing it again.

I absolutely agree with this. One of my more flighty cow-orkers sent round this link yesterday - calling maintenance programmers "the residue". Yeah, him and his mates have been talking non stop about how shit systems X, Y and Z are, how they could do so much better etc. Meanwhile, that system, that I maintain is paying all of our salaries. And those boys have produced something approximating... sod all. While getting paid by the revenues generated by that old code.

http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...

Inversely I have had experiences with maintenance coders going like mercenaries into code i wrote and without respect for architecture or future extensions making changes because they didn't understand the code and we're not interested in the concepts behind it.

going like mercenaries into code i wrote and without respect for architecture or future extensions making changes because they didn't understand the code and we're not interested in the concepts behind it

This is a problem even when the maintenance programmer is not a mercenary. Check out the essay by Peter Naur (the N in BNF) called "Programming as Theory Building". It's one of the best things ever written about software (albeit in disappointingly bloodless language) and explains this masterfully. http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn...

The essential point is that source code and documentation, no matter how well-written and extensive, are insufficient for understanding a large system. You have to have the "theory" (the article explains what this means) and for this you have to have someone who knows the theory.

I've been afraid of this too.

I wrote a system in C# that used immutable data and actually used that to do rollbacks when evaluating a scenario failed. My fears was that since there are no "val" and really bad immutable collections in C#+.Net the maintenance coder would probably remove list.AsReadOnly() and putting in public on setters as part of fixes to bugs.

That didn't happen though, the maintenance guy was really smart and got the ideas without me explaining much more than mentioning immutability.

But this is why languages like Scala are important. Immutability and similar design(patterns) are a result of discipline and sometimes convention in languages like Java and C#. It's bound to fail due to humans being humans.

Why would ones ability to "spin stories and slag off others" be exclusive to their programming ability? I almost want to argue that they're demonstrating some form of communication skills, which may translate to more readable/maintainable code? ... Maybe that's a stretch.

There are people who hustle for the business, and people who hustle only for themselves. We're talking about the latter.

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.

Agreed. My net total for LOC written in the past year is probably -700, because I've refactored so much verbose code.

I don't know how to count unit tests in such a metric though... because I took a code base from 2% code coverage to 70% and that meant writing something like 200 LOC in unit tests alone per day, even though the actual code being refactored under these tests diminished in size.

I'd count the unittest code too, it needs to be maintained too.

It's easier to maintain unit tests if you write unit unit tests for them.

You laugh, but if someone accidentally shipped some code in their unit test library that made assertEqual(1, 2) always return true I might be a very unhappy camper.

Well, this does not address one of his core argument, which is basically coding for average Java developer is just one small part from his/her day activity.

Especially in the case of maintenance of existing legacy system, where most of the activity resolves around understanding existing code, writing is just a small part of it. If maintaining the system needs to be financially feasible, hiring expensive Scala developer may not be the best idea to maintain the system. Unless of course, using Scala outweights the benefits of using Java even with the potential financial cost.

Note also that code of average architectural quality will require about 1 maintenance day per year per 80 LoC just by virtue (vice?) of existing. (Paul Graham: a full-time maintenance engineer can own 20,000 lines of code.)

This is true in my personal observation. I mostly wrote two pieces of software rougly 50,000 lines each, and it's my limit of manageability. Will need splitting up and modularizing if it needs to get larger.