Maybe I'm out of the loop, but is it really this bad out there in the real world?
I took some high paying contractor gigs through an agency a few years ago because I wanted to figure out what direction to take in the next phase of my career, the cash was great and I'd never worked in the fortune 500 / government contractor kind of space before.
I wasn't that surprised when I got told that I was now their second developer (out of a few dozen) who "actually writes code in his free time sometimes! isn't that crazy!" since I was prepared for big company suit world.
The reality was right in line with the quote, if not worse.
Myself being a optimist, I don't believe that statement, there is probably someone. It has to be. Then again it could just be my wishful thinking.
I also saw the appeal of that side of the industry. These guys all had way more varied hobbies and family lives since the programming stuff is "just my job" and had a good stable career path because any motivation we in the hacker news crowd would spend on learning new cool stuff they spend on jockying for position in the big office social/political world.
The lure of the office drone never got me though, it was too obvious to me that you are just selling the best part of your day for most of the week during the best part of your life only for money, since the actual hours are spent doing something you are marginally competent at and find uninspiring.
I thought we had gotten past LoC as a measure of programmer productivity?
Hacker News gives us a rose-colored view of the software industry-- one in which knowing about functional programming and agile methodologies (regardless of whether one intends to use them) is a prerequisite for being considered literate, and in which 200 line-per-day development on new invention is something people can actually get paid for. That's now how the average developer experiences software.
BTW, this is one of my startup rules: measure what's important. Decide what's important by how it would affect your decision-making.
However, that depends on who you ask. Specifically, try banks (and other financial institutions), Fortune 500 companies (exclude the more tech savvy such as Google, Microsoft as the code that does get written is meaningful), and anywhere that is infested with suits.
And, by the way: I believe that, out of the 20, 15 are XML.
But using LOC as a measure of work quality or suitability for learning another language is really ludicrous. I would really hope that most people in the industry and Java programmers in particular are capable of learning Scala. I like to think that suitability of the language for a task is a quality of a language not the programmer. Yes, all languages in use are Turing complete, but some are better suited for certain tasks. The question we should be asking is what kinds of projects Scala excels at, and what kinds of applications is it really good for?
And yet think you are part of the group mentioned by the article?
Lines of code is an awful metric of productivity but, yes, that figure of 3250 is accurate. Between 1,000 and 10,000 LoC per year is normal for a software engineer in the industry, and the rate is often closer to the lower number.
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.) LoC are a cost: if we rate a developer's time (including benefits, office space, etc.) at $80/hour and charge each LoC for 4 years, we pay $32 per line of code in maintenance. (We spend $2-3 per line to write it.) That is, IMO, a pretty accurate estimate of what we pay for software.
If you write at 500 LoC/day under ideal circumstances but you're writing code that's merely average in architectural integrity, the maintenance problem will catch up with you very quickly.
It's a lot better to write 150 lines per day of great code (200-300 including unit tests and debugging utilities) and maintain that pace than to start out at 500+ but stall out late in the project. Great programmers don't write code at college-project speeds; they write in such a way that they can sustain triple-digits in perpetuity.
A single developer solves this problem by refactoring the code when necessary and incrementally improving the architecture so as to reduce the maintenance cost. It's only by doing this that projects beyond about 15,000 lines of code per person (75% maintenance burden if code is of average quality) are even feasible.
It's not just a problem of incompetent developers. Maintenance imposes a 70 to 90% overhead on most important projects in large companies, just because these projects become difficult or impossible to refactor and fix and their "broken windows" patterns of decline take on a life of their own. Individual developers can refactor aggressively when their maintenance burden breaks 50% (70% being a crisis) but this is not usually feasible for multi-developer enterprise projects that have changed hands several times.
The more progressive large companies now actively discourage any mention of LoC in performance reviews. First, deleting unnecessary code is one of the best things a person can do for a code base. 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.
http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...
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.
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.
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.
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.
(also it means that they are pretty fanatical programmers thus that they're self-motivated)
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. ;)
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.
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.
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.
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.
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.
So the number is really more reflective of how much an organization lumps under "software engineering" and how much general overhead its processes incur than it is of the productivity of individual programmers.