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 logthat causes it to ignore pure file movements.
Our server is about 2mb of Python (as per the
/repos/<our org>/<our repo>/languagesAPI endpoint). This is about 30k lines as reported by
find . -name '*.py' | xargs wc -l;
sloccount .gives 20k. My favorite metric of codebase complexity—lines of code as reported by
coverage.py—says we have about 7.5k lines that actually matter. (The rest of the
sloccountlines 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…)
sloccountestimates 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.)