This morning I started to play around with sloccount
and Git’s commit graphs for the Wave repositories. Some fun facts about the Wave server:
I’ve added about 1/3 as many lines as our other engineers, but removed just as many lines. I AM THE CODE DESTROYER.
Actually a lot of this seems to be driven by me being responsible for the commit that moved our tests to a different directory, which added 5k insertions and 5k deletions (and made me look super productive). I’m not sure if there’s a flag you can give
git log
that causes it to ignore pure file movements.Our server is about 2mb of Python (as per the
/repos/<our org>/<our repo>/languages
API endpoint). This is about 30k lines as reported byfind . -name '*.py' | xargs wc -l
;sloccount .
gives 20k. My favorite metric of codebase complexity—lines of code as reported bycoverage.py
—says we have about 7.5k lines that actually matter. (The rest of thesloccount
lines are tests and scripts.)Our clients (Android and iOS) are each a bit bigger than our server, but not much. I guess if anything I would have expected the difference to be starker, since UI logic is super complex, but we have a fair amount of complex logic on the server as well to deal with all the crazy corner cases and error handling.
Our iOS app is about 3k more SLOC than our Android app for approximately the same functionality. But there are a ton of confounders. (Different programmers; IIRC the iOS app was written first; the iOS app may have been more thoroughly tested/debugged…)
sloccount
estimates 4.5 person-years to develop our server, which I think just means that its estimates are super bad since the true number is probably ~1 person-year.Even excluding that one commit of mine with 5k insertions and deletions, I have the largest commits at ~50 insertions/commit; our CTO has the smallest at ~20 insertions/commit. (On the server—on the client we have a bunch of vendored dependencies that make the numbers less meaningful.)
Comments