[whstl]

IMO it's like scrum: if your team is good and homogeneous, it doesn't really matter much what you do: it just works. Scrum and no scrum, types and no types. It's not about having rockstars or 10x engineers, it's just about having shorthands, shared knowledge, etc.

If your team is varied or too large, you need things to help you out with organisation and communication.

(Whether my examples of Scrum and Types are the answer: depends on the team unfortunately)

[bluGill]

In my experience: Too large is any team larger than 10 people or any code base with more than 10,000 lines of code. Both of those would be considered tiny by most in the industry.

[whstl]

Oh, you are definitely correct about 10 people being too many. For me I think the magic number was 4 or 5.

About 10k lines, I really never stopped to think but I'm gonna guess you're correct on that too.

[bluGill]

The numbers I gave are not exact. Depending on details that I don't think anyone entirely knows. Sometime 1 person is too many (generally implying a bad programmer), while other times you can get a bit over 10 if you have strong discipline. Likewise strong discipline can get you to 100k lines. Really what this is about is how much pain you are willing to put up with. 10 people and 10k lines of code are good round numbers to work with.

[default-kramer]

Hard disagree on the 10kloc limit. At a previous job, I maintained and enhanced a 50kloc monolith (written by someone else), usually by myself. My productivity was very high. At my current job, we've split a codebase that should be about 50kloc into more than 10 separate repositories; everything is still just as coupled but it's much harder to reason about and refactor. My productivity is much lower.

[thot_experiment]

Agree, people underestimate the cost of interfaces that don't sit exactly where they need to sit (which is almost always the case)

http://number-none.com/blow/john_carmack_on_inlined_code.htm...