Wildfalcon

This recent post by Ola argues that if you plan to write big software, you have already lost. He is talking about why we should not write projects with many many lines of code. To me, this is a bit of a truism. Is it not always the case that doing the same thing is less lines of code is better?

Well, as long as your not talking about deliberately minimizing and obscuring your code I think it is.

“Big projects” get a lot of flack from the development community, but I don’t know – what is a big project? Is it:

1. A system that has many lines of code?
2. A system that has many developers working on it?
3. A system that has many features?
4. A system that has many users?

I don’t think anyone would agree that choosing 1) as your goal is a good thing.

There are obvious reasons why 3) and 4) are desirable goals (even though you may, rightly, question those reasons).

2) Is interesting. Its often arrived at for historical reasons, such as “we brought a company, so got all their developers”, productivity reasons; “100 programmers have to be able to add more features than 2, right?”, or even publicity reasons; “We have the biggest best team working on this”.

Each type of bigness has its own problems. Which big are you complaining about? What is the best way to fix those specific problems?