Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not convinced. I worked on a project with some friends that got to about 20kloc and then collapsed under its own weight because it became impossible to change anything without breaking something else. While there's a wrong way to design for scaling or extensibility, development practices that rely on holding the whole thing in your head will hit a brick wall sooner or later.


It's fascinating reading posts like this from people who have actually put in the work on 20k+ LOC projects with multiple people and those who just repeat a few articles or blog posts they read.

The difference is stark.


I find the comment a little rude, as if implying the grandparent poster (me) "just repeat a few articles or blog posts they read", whereas the anecdotal parent comment about a 20k+ project they've worked on shows the real experience.

I've worked in multiple 20k+ LOC projects with other people and everything (teams of 10 or more people are good enough to you?). And 20k+ is not even that big, it's not like it offers any great insight regarding software development.


I don't think the size of a project is that important if you're looking for insight into software development. There's certainly poor ways to go about developing small and large projects and most of the insight is to be gained from looking at the mistakes (and lack thereof), whether it's a 100 line piece of glue you wrote which became unreliable and caused major issues or if it's some 100k line project which became increasingly difficult to maintain.


There's a difference between making something a scalable and extensible product from the get go, and writing unmaintainable code.

You can write simple and maintainable code for a simple product which isn't scalable or extensible.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: