Is there a "Large Scale Python Software Design" ?

[Dave Brueck]

Josiah Carlson wrote:
>>Heh.  "Large" depends on a lot of things, particularly connectedness,
>>but I really can't picture 10k being large under any circumstances.
> 
> 
> Ok, so what is large?  How many orders of magnitude larger than 10k
> lines does it take for a piece of software to be large?  And why should
> you be the judge?

I think the only way to compare projects is from a user's or customer's 
perspective - what functionality the application provides & its scope. Any 
comparison involving lines of code or number of developers won't be reliable 
unless other factors (especially implementation language & libraries) are held 
semi-constant. For example, at one company I think the total was 1.1 or 1.2 
million lines of code (all C++ & about 60-70 developers), and yet I have trouble 
imagining how, if I could go back and do it again in Python, it'd take even 200k 
lines of code (and the riskier side of me feels it'd come in at under 100k - it 
just didn't _do_ a lot despite all that code!)

In that sense, a 10k Python app can be fairly large in terms of end-user 
functionality. For example, our main product where I work consists of *many* 
different custom servers, a full web-based administrative interface, an end-user 
web interface, a client application that does all sorts of interaction with the 
servers, and lots of database interaction. Add to this many internal tools, 
integration tools we provide to our customers, etc., and I would rate it overall 
as on the upper end of medium-sized projects, functionality-wise - not the 
largest I've worked on but well beyond any definition of small, and our plans 
for the next few quarters will definitely push it into the range of what I'd 
normally consider a large system. IIRC we're only in the 10k-20k for lines of 
Python code, plus a few modules here and there being C++.

Having said all that, I've found that competitors in our same space tend to have 
20-30 developers on the low end to over 100 on the high-end, while we have but a 
handful. We don't have quite the same breadth of functionality - at least not 
yet - but we generally make up for it by accounting for it architecturally but 
not adding it until a customer actually needs it (a sort of JIT approach to 
development). As such we've been able to compete head-to-head with others in the 
same sector. On more than one occasion I've wondered aloud how so many 
developers working for Competitor X can stay busy, and I can only imagine how 
many lines of code they're churning out - and yet, from a functionality 
perspective we're keeping pace. I also wonder how many hours a day they spend in 
meetings trying to coordinate everything. Ugh.

Back to the point at hand: a project using a higher-level language gets out of 
hand more slowly; if there were no other advantage it'd still be a "win" IMO 
because you encounter "big project" problems a lot later - and that's a huge 
benefit in and of itself.