Norris Numbers
teamten.com
Norris Numbers
1–10 of 28 posts
Re: Norris Numbers
#2As someone who has never really programmed in a group, what are some examples of common scaling issues? I typically try to adhere to the principles of loose coupling, pure functions & immutability, clean & readable syntax, "don't reinvent the wheel", algorithmic optimization before code optimization, version control, unit testing, etc.
But I'm curious: what useful principles have other HN users acquired after decades of programming or working on giant projects that a "solo programmer" like me might not be aware of?
Re: Norris Numbers
#3That's a very unappealing title for a very interesting subject, which is that there are complexity barriers that get in the way of creating larger programs.
For the sake of illustration, he says a novice may hit a brick wall at 2,000 lines of code, and be unable to add features after that without breaking things.
The next level for a more experienced programmer might be 20,000 lines of code, and he describes some things that helped him get there.
Then there's his personal breakthrough to 200,000 lines of code. etc.
(I add this gloss to spur people to read the piece, which is interesting, and add their own ideas, not because I am claiming the above is some kind of absolute truth.)
Re: Norris Numbers
#4[deleted]
Re: Norris Numbers
#5As someone who has never really programmed in a group, what are some examples of common scaling issues? I typically try to adhere to the principles of loose coupling, pure functions & immutability, clean & readable syntax, "don't reinvent the wheel", algorithmic optimization before code optimization, version control, unit testing, etc. But I'm curious: what useful principles have other HN users acquired after decades…
Great question.
For me one of the biggest shifts was test-driven development. That is, I start with a test, write a few lines of test code, make it pass, perhaps refactor, and write a few more lines of test. It took me a year or so to get from test-last to test first, but I love it now; it forces me to look at code from the external perspective. One way to put it is that it shifts my focus from internal mechanism to real-world meaning.
Another breakthrough was pair programming. The larger a code base gets, the more important readability and easy comprehension get. But at least for me there's a real limit on how comprehensible I can make a piece of code on my own. I just know the internals too well to usefully model the reaction of somebody who neither knows the internals nor wants to. But pairing gives me (and allows me to give) continuous feedback on what makes sense and what doesn't.
A third favorite is known as Domain-Driven Design [1], where one organizes the code around the actual concepts of a business domain. The larger a code base gets, the more possible places one might look for a particular piece of code. Organizing the code by the real-world notions is a great check on entropy.
Re: Norris Numbers
#6As someone who has never really programmed in a group, what are some examples of common scaling issues? I typically try to adhere to the principles of loose coupling, pure functions & immutability, clean & readable syntax, "don't reinvent the wheel", algorithmic optimization before code optimization, version control, unit testing, etc. But I'm curious: what useful principles have other HN users acquired after decades…
A large software project is about communication more than anything else. Inside a company, a large codebase is often extremely hard to navigate. There will be different coding styles, redundant library usage, outdated comments, obsolete / unused code, code written by people who left long ago, ugly workarounds for OS / api bugs that may no longer exist.
You may find pieces of beautiful code written by enthusiastic new employees next to files written by jaded, checked-out veterans ready to move on. Coffee-fueled bug fixes checked in right after the tests passed, to be documented later (never). There may not be a person in the organization who knows how to fully build and deploy an entire codebase from scratch.
You'd think this only happens at "bad" companies, but any company that grew fast and became hugely successful will have lingering technical debt, some of which does not need to be paid.
If you want to experience this, pick a relatively unpopular and large codebase open sourced by some company and try to understand it. Imagine someone had just asked you to add a new feature with an arbitrary deadline. Now realize that this code is probably much better than a comparable closed-source system, after all the company wasn't embarrassed about sharing it with the world.
Re: Norris Numbers
#7That's a very unappealing title for a very interesting subject, which is that there are complexity barriers that get in the way of creating larger programs. For the sake of illustration, he says a novice may hit a brick wall at 2,000 lines of code, and be unable to add features after that without breaking things. The next level for a more experienced programmer might be 20,000 lines of code, and he describes some thi…
And that's exactly what's wrong with all the syntactic-sugar-based language marketing. "Write your code using X, and you go from 10 ugly lines of C++ down to 3 beautiful (if syntactically weird) lines of X!"
Great. Now tell me how X scales on a 200,000 line project.
One of the places people make this mistake is with Go. Go isn't designed to make your 2,000-line project shorter or easier. It's designed to make Google's 20,000,000-line projects maintainable for a couple of decades.
Re: Norris Numbers
#8That's a very unappealing title for a very interesting subject, which is that there are complexity barriers that get in the way of creating larger programs. For the sake of illustration, he says a novice may hit a brick wall at 2,000 lines of code, and be unable to add features after that without breaking things. The next level for a more experienced programmer might be 20,000 lines of code, and he describes some thi…
And that's exactly what's wrong with all the syntactic-sugar-based language marketing. "Write your code using X, and you go from 10 ugly lines of C++ down to 3 beautiful (if syntactically weird) lines of X!" Great. Now tell me how X scales on a 200,000 line project. One of the places people make this mistake is with Go. Go isn't designed to make your 2,000-line project shorter or easier. It's designed to make Google'…
The traditional wisdom (backed by multiple studies starting decades ago) is that the language used doesn't statistically change the number of debugged lines of code per day, but may often change the number of machine instructions executed per line of high level code written.
We are digressing here, yes? I read the article quickly, admittedly, but I didn't notice him doing language advocacy.
Re: Norris Numbers
#9I think the most important takeaway from this article might get lost in the other points it makes: you are better off when you have fewer features and have fewer features that interact with each other.
20KSLOC programs just don't appear out of thin air. They start as small programs that, if you apply good programming practices, can scale beyond 2KSLOC. And if you apply good program design practices can scale up to 20KSLOC. But all along the way you'd better be thinking about whether you really need a particular feature and how coupled it will be with the other ones. That should happen in every program. The problem is that we are not used to challenging the features that are selected for our systems and recognizing their price as the system grows.
Re: Norris Numbers
#10Earlier quoted context omitted.
And that's exactly what's wrong with all the syntactic-sugar-based language marketing. "Write your code using X, and you go from 10 ugly lines of C++ down to 3 beautiful (if syntactically weird) lines of X!" Great. Now tell me how X scales on a 200,000 line project. One of the places people make this mistake is with Go. Go isn't designed to make your 2,000-line project shorter or easier. It's designed to make Google'…
The traditional wisdom (backed by multiple studies starting decades ago) is that the language used doesn't statistically change the number of debugged lines of code per day, but may often change the number of machine instructions executed per line of high level code written. We are digressing here, yes? I read the article quickly, admittedly, but I didn't notice him doing language advocacy.
Yes, I'm digressing. Guilty as charged. Nevertheless, I think it's a somewhat-on-topic digression.
If there's a wall at 2,000 lines, almost all language-advocacy examples are below that wall. That's the first wall. But language choice doesn't get interesting until you ask what the language does at the 20,000-line wall or the 200,000-line wall. Nobody talks about this when they advocate a language (except, as I said, Go). The closest are Haskell and Lisp, and their claim is that you can write the same program in fewer lines (so that you don't hit any of the walls as quickly).