site banner

Small-Scale Question Sunday for May 3, 2026

Do you have a dumb question that you're kind of embarrassed to ask in the main thread? Is there something you're just not sure about?

This is your opportunity to ask questions. No question too simple or too silly.

Culture war topics are accepted, and proposals for a better intro post are appreciated.

2
Jump in the discussion.

No email address required.

What is the right way to talk about the size of a programming project?

I recall someone in a thread a while ago making a dismissive comment about amateurs with AI boasting about how many lines of code they've written, which I think was either referring to me talking about my own vibe-coded project or possibly Garry Tan boasting about 37k LOC per day, which does seem slightly excessive.

I know that less is more, efficient code is better than lengthy code and that AI tends to leave a bunch of comments in there too... but how can you measure the complexity of a project in any quantitative sense besides lines or just outright KB/MB? I'm not a 'real' software engineer but it seems like once you have 134 files and 3.4 MB of code, you can't really count functions in any useful way, what else is there but lines and size?

This is a really hard question, because not all lines of code are created equal. A line of Haskell or Scala can be far more dense than a line of say, FORTRAN, and God help all of us if we start talking about Perl.

The comment below about cyclomatic complexity is a good one, especially in conjunction with line count. Internally at work, we also talk about how compressible code is as a mostly-serious joke. It's actually not the worst rule of thumb. If your 3.4Mb of code compresses down to a 5kb zip file, you don't have 3.4Mb of code - you have 3.4Mb of copy/paste.

As an old guy, I've always held that every line of code is a liability. Every branch is a new set of tests that you have to write with a new set of expectations to figure out.