The real interesting corollary here is that no matter what level you are at, you will probably want to leverage a language that's as powerful as possible, since you will be able to accomplish more with less lines of code[1].<p>A few months back, I expressed disappointment with Google Maps' dropping of support for displaying KMZs from other servers, and my intent to put together a replacement. When I finally got around to it, I found a JS library[2] (plus plugin[3]) that allowed me to replicate what I needed in about 10 lines of JS[4]. Of course, this is more the power of leveraging a library (and public tile servers), but I think it's still instructive to my point.<p>[1] - <a href="http://www.paulgraham.com/power.html" rel="nofollow">http://www.paulgraham.com/power.html</a><p>[2] - <a href="http://leafletjs.com/" rel="nofollow">http://leafletjs.com/</a><p>[3] - <a href="https://github.com/mpetazzoni/leaflet-gpx" rel="nofollow">https://github.com/mpetazzoni/leaflet-gpx</a><p>[4] - <a href="http://hardcorehackers.com/~npsimons/photos/2014/07-13:%20Owens%20Point/gpstrack.html" rel="nofollow">http://hardcorehackers.com/~npsimons/photos/2014/07-13:%20Ow...</a>
<i>The real trick is knowing when a new feature adds linear complexity (its own weight only) or geometric complexity (interacts with other features).</i><p>This is why so many folks love DSLs. Fully abstract and get your geometric features out early; test them and make them flexible without having to re-code anything.
There is shockingly little data on this available. The most systematic research I have found was led by Lehman at Imperial in the 90's : <a href="http://www.eis.mdx.ac.uk/staffpages/mml/feast2/papers/abstracts.html" rel="nofollow">http://www.eis.mdx.ac.uk/staffpages/mml/feast2/papers/abstra...</a><p>Interestingly I am in a position to revisit the evolution of one of the systems in the FEAST study. The key insight from FEAST was the idea of an "S-curve" where complexity overwhelms drive for features. Initial development progress is slow because the infrastructure and framework for the system is not in place, then comes rapid development then a slow down as complexity kicks in.<p>The reviewed system behaved like that in the study (I checked the data) and for a few years after. But then a period of explosive growth occurred, halted only by a strategic decision to move away from the platform for technology management (obsolescence of mainframes) reasons.
I've never coded a piece of software that needed 3 million lines of code. I'm at the 200,000 LOC level right now.<p>However, from my software architect experience I imagine that any project in the millions of lines of code would be best broken into smaller services that communicate through a common backbone.<p>This type of architecture would allow a large dev team to be broken into smaller groups that each focus on smaller, manageable subsets of the large code base with each subset being a service which then communicates with other subsets through a backbone.<p>It would require a lot of internal documentation and back and forth communication between internal teams to get the services to integrate with each other flawlessly but it shouldn't be too difficult with proper care and talent.
Is this 1500 lines in a monolithic program with no structure?<p>Certainly I found no problems in working with some of the billing systems I worked on at BT which had way way beyond 2k loc and probably around the 200k.<p>I recall 1400 long line if blocks in one bit of fortran 77 code :-)<p>But we did have a real genius as team leader
How many lines of code is our DNA? Could there be a similar effect at work in other systems, concerning network size and orthogonality that limits their size? Things like the amount of complexity in DNA of organisms, or the size of cells, etc.?
This is a very interesting phenomenon, but I think one should be wary of using it for decision-making in the absence of distinguishing principles. "Keep things simple": yes, of course, and I also look both ways before I cross the street.<p>Believing in this phenomenon has promotional value - those other guys just don't "get it." I worry that deeply internalising it bears great risk of self-delusion. Acknowledgement of this phenomenon, irrespective of whether it exists or not, may prove detrimental.<p>One need not heed the arguments of those lesser 2,000-liners; only a 200,000-liner possesses the <i>je ne sais quoi</i> to know the right choices.
I'm not convinced by the "number of lines" measure unit. It's clearly something which depends on the programming language, so one should gather different statistics depending on the language. Not to mention the fact that different projects might be prone to get messed up in different ways...
I don't see how "refuse to add features" allows complexity to scale past 20K. That seems more like a strategy to stay under a given number of LOC, dodging the issue (which isn't to say it's a bad strategy).
The article has some valid points. But a person who needs to emphasize his superiority against novice programmers in such a way lacks maturity of personality.