-2000 Lines of Code

I had a job interview once where the HR rep asked me how many lines of code I wrote a week. I responded, &quot;On a really good week -1000, I don&#x27;t remember the exact figure.&quot; She was extremely confused by this answer and wanted me to give her a number. So she said, &quot;I&#x27;ll just put down 10,000.&quot;<p>This is also the interview where they refused to continue unless I told them how much money I made (which I don&#x27;t do anymore). The justification they told me was that they weren&#x27;t going to give me a 20K raise if I wasn&#x27;t making that much right now. I didn&#x27;t point out that they aren&#x27;t giving me a raise, they are paying me market value based on what the position is worth (to oversimplify it).<p>I was offered the job but decided not to take it because that plus the technical interview made me wary.

It&#x27;s not just old managers that dislike negative lines of code: Static analysis tools dislike them too, under the right bureaucracy.<p>At a certain huge company that sells seeds, they decided to start having both a base test coverage target, and a specific plugin that demanded that the coverage never went back more than half a percent from the high water mark on any given project. The engineering managers thought it was a good idea: As time goes by, we&#x27;d have better code coverage!<p>I joined a team that had an application full of repetitive code, because nobody had spent much time thinking about reuse. I decided it was bad for maintainability, and the team let me rewrite a big chunk of repetitive, well tested code. I shrunk the codebase by a good 10K LOC, and it still did the same thing. Teammates liked what I had written, and everyone was happy. But when I pushed it, the build refused to deploy, because now the code didn&#x27;t meet coverage standards.<p>The manager was mad at me: you wrote all that code, but I guess your unit tests were sloppy! he said. But when I went and looked at the code changes, I had a 100% code coverage. Since I am not a football player, I just couldn&#x27;t give 110%. So then we look at the reports, slowly, and saw that while I had full code coverage, the code I was replacing also had full code coverage, but mine was so much smaller, our total coverage percentage went down! 1000 lines of uncovered code, in a codebase with 30K lines, gave us better numbers than the same lines in our shinier 20K LOC codebase. And building tests for some really old, badly factored code just wasn&#x27;t in our top list of priorities.<p>The people in charge of this system refused to change it, even though it was really not helping things in our case. So what did we do? Fool the tool, of course. Added a bunch of well tested dead code that was never going to get called in production, and wouldn&#x27;t even get built into the binary, thanks to some packaging magic. We put it in a separate module, clearly marked as &#x27;dead code to make Sonar happier&#x27;, and we went our merry way.

4 months into a new job, and I realized I had contributed about -4000 lines of code. I thought, how weird it would be to explain (especially to someone less technical), that I&#x27;d pretty much just been deleting code since I started. I&#x27;d also added a number of important features along the way.<p>Since then, I&#x27;ve taken some pride in trying to be a &quot;net negative&quot; (by line count), contributor to any code base I work on. Not always possible, but it&#x27;s a good mindset to strive for leaner designs&#x2F;implementations.

&quot;If we wish to count lines of code, we should not regard them as &#x27;lines produced&#x27; but as &#x27;lines spent&#x27;.&quot;<p>- Edsger Dijkstra

One of the most interesting experiences I had very early on in my career was reducing a 12,000 line C program to a roughly 1,000 line version (in C itself) without losing any functionality.<p>No, it had nothing to do with my prowess as a young coder, but solely due to the fact that my predecessor did not know what a function was nor how to use parameters.<p>He had written unrolled versions of the same piece of code, with embedded SQL with minor variations in WHERE CLAUSE values which could be easily parameterized.<p>All I had to do after analyzing the code was move the code into a function and loop through it with different parameters values.<p>Such is life.

I worked at a furniture company where in order to delete code you had to have the head IT guy, the IT Director and an outside consultant sign off on it. Yes, that is right! 2 people that didn&#x27;t know how to code and an outside consultant that we paid to look over &quot;IT&quot; moves before we made them.<p>However, I didn&#x27;t need anyone to sign off on commenting out code and replacing it with something else. :-)

&quot;One of my most productive days was throwing away 1000 lines of code.&quot;<p><pre><code> — Ken Thompson </code></pre> <a href="http:&#x2F;&#x2F;quotes.cat-v.org&#x2F;programming&#x2F;" rel="nofollow">http:&#x2F;&#x2F;quotes.cat-v.org&#x2F;programming&#x2F;</a>

Brings to mind the classic:<p>&gt; &quot;Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.&quot; - Bill Gates

I finished up a 24-month project earlier this year on a codebase of ~1M lines in which I dropped a net of almost 100k lines of code and reduced the main Visual Studio solution from 325 projects down to 105 projects. Compile times dropped from ~40 minutes to 6 minutes. If only all my projects could be that fun.

Once had a compiler QA gig. Was kinda lazy. So, I wrote a nonsense code synthesizer. Just take the BNF and belch out code. Millions and millions of lines of code. A fun variant was to create a class hierarchy that would run 100&#x27;s of levels deep. I showed it to marketing. They asked: &quot;Can you do that for &lt;competitors&gt; compiler?&quot; &quot;Sure thang!&quot;. Soon, there was an ad showing how our compiler could handle a lot more bloat than their compiler. Not my proudest achievement.

Imagine being a civil engineer, and your boss says &quot;how much concrete did you use? I&#x27;ll pay you to use more.&quot;<p>Or an electrical engineer: &quot;How many resistors did you solder? I want them all gone.&quot;<p>Or an aeronautical engineer: &quot;What does the plane weigh? I was expecting a few more tons.&quot;<p>Or a traffic engineer: &quot;Why haven&#x27;t you put more stop lights in?&quot;<p>Or a mechanical engineer: &quot;More gears!&quot;<p>Always hard to get the bean counters to appreciate elegance.

I worked somewhere where the support manager somehow managed to get approval to bill his costs against each product group based on the lines of code in their product. We spent part of a week refactoring and reformatting to cut it by 70% before we gave him our numbers.

I wish the output from <i>git diff</i> used red for new lines and green for removed lines...

This story is about how useless LOC is as a metric.<p>But negative LOC alone is just as useless a metric as positive LOC. It&#x27;s easy to come up with examples where deleting unused code is actually harmful:<p>- Just delete all comments<p>- Remove platform code you are not using now, but might in the future<p>- Remove reference code because you are only using platform code<p>- Remove test code that is just not called yet, but really should be<p>- Remove code from a copied library that is now harder to keep current<p>- etc..

Writing code is like playing jazz. It&#x27;s not about the notes you are playing, its all about the notes you are not playing

I deleted a couple thousand lines this week. It felt awesome. But you&#x27;d have to admit that rewarding based upon deleted lines of code could be even more dangerous than rewarding added lines of code.

Porting a large piece of PC code to a console:<p>- every deleted line meant we could have more content<p>- the code ran faster<p>- there were, axiomatically, fewer bugs (and we fixed a lot of bugs on the way)<p>- the code was more understandable

I work on a large Android app.<p>I have absolutely no idea of what my average LOC &#x2F; week is and I would argue that it is a silly metric.<p>Last week I deleted 30k LOC from the project (~10% of the code base) :<p>-we used to have both the old &amp; new version of the UI in the codebase so we could switch between the twos in production. Now that the new version is complete, there is no need for that.<p>-There were many deprecated parts of the app and unused resources, I did a big cleanup of these and I have even more work in that area.<p>This has resulted in way cleaner code, easier to apprehend for newcomers. The app is also lighter by 2 mo. Probably a very productive week overall.

Folklore.org has plenty of other great stories from the Mac team. I remember reading some of these long before the Steve Jobs biography was released.

I deleted 205 today. Felt good.

I was surprised when YC asked something similar in their application:<p>&quot;If you&#x27;ve already started working on it, how long have you been working and how many lines of code (if applicable) have you written?&quot;<p>My response ... &quot;I personally believe that using &quot;lines of code&quot; is a crude metric as it favors the sloppy programmer who doesn&#x27;t write compact code and discourages code reuse by utilizing libraries and frameworks.&quot;

Similarly, the number of git-commits is also a poor judge of how much work was done. When CI builds automatically build release notes based off of the git-log since the last successful build, this can be deceiving.

I guess the management finally realized that deleting codes without breaking existing functionalities is more difficult than adding :)