[gburt]

Counting lines of code, commits, changesets or any other simple metric will destroy your culture.

The team _will_ find out, and then instead of contributing to the success of the business in earnest, they’ll be doing stupid things like maximizing their changesets or racing for “easy” large changes like deleting a module.

It doesn’t matter whether those values do or do not correlate with reality (IMO, if they do, it is for relatively junior engineers only). If you give off the smell of measuring people like that, you will ruin any collaborative team environment and you risk never being able to recover that.

There’s a good chance you’ll chase away excellent engineers with this sort of low-effort metrics management too.

[startupsfail]

Massive amount of code, particularly when written by a single engineer more often ends up being a liability, not an asset.

There are exceptions, but these are extremely rare.

Look for code created in collaboration by multiple engineers, with contributors or reviewers across multiple teams. This code is more likely to be an asset.

(Unless created by Google for external use or by xOoglers. Such code outside Google is a near guaranteed liability.)

[admax88qqq]

Most great frameworks and libraries start out as a massive amount of code by a single developer. Ver few good frameworks were designed by committee.

A single opinionated developer laying the foundation and core architecture is important for getting a coherent developer experience.

[startupsfail]

This results in yet another opinionated framework in which that particular developer is extremely prolific. That developer then keeps making massive changes to the framework, deprecating and renaming parts every so often. At some point other engineers, who initially had been excited, get tired of the tyranny, rebases, rewrites and having to fix their functionality broken by framework changes. Then, the opinionated developer gets into disagreement with the management (that is getting more and more concerned by the constant churn and lack of new features). Being up to speed and fully convinced that he is the most prolific in the team, he decides that the management is unreasonable, easily finds another job and abandons the project. The codebase dies.

[admax88qqq]

Sure that's one possible outcome if that developer is a poor leader.

The other outcome if that developer is a good leader and interested in developing a community is that a community builds around the core foundation that was laid and begins to take a life of its own.

Look at React. Started by a single opinionated developer who laid the foundations and built a prototype. From there it's taken on a life of its own and evolved. It was not designed/built by committee from day 1.

Or python for that matter.

[bigDinosaur]

This is a very general statement that I'm not sure is necessarily true at all?

[fredophile]

On the balance sheet I'd call functionality an asset and code a liability. Everything else bring equal more code is more to maintain as things change, search through for bugs, etc.

[tobyjsullivan]

You're absolutely right. It's also true that counting lines of code is foolish and almost certainly counter-productive. But to your point, the argument is simple. People who ship lots of value will, more often than not, also ship lots of code changes (not necessarily net additions). The oft conflated group who ship lots of code, but little value, usually won't make it past code review (and, hence, don't actually ship all that much).

Contrary to some other comments, I'd argue it's the people who ship lots of value, but very little code, who are rare to find in practice.

[startupsfail]

Yes, for relatively small projects the above is true - software engineers who ship lots of value, but little code are rare. For slightly larger projects they are not so rare. Systems or integration engineers do less coding, but can make the whole thing actually work end-to-end. Engineers that change projects within the company can have drops in their contribution rates, but their wide knowledge can prevent many-a-mistake from happening.

Looking for healthy collaboration is the key, this is where the magic usually happens. Counting lines of code is a poor proxy for this.

[yellowapple]

I reckon I could count the counterexamples on one hand.

[njovin]

> Counting lines of code, commits, changesets or any other simple metric will destroy your culture.

Counting them alone won't, but incentivizing people based on changesets will. IMO there are plenty of cases where counting LOC is useful to a manager. It's a discrete piece of data than can be combined with other data to make informed decisions as a manager.

[Retric]

It’s very high risk and low reward. I have heard of a very valuable employee quitting on the spot when they discovered their manager was doing this kind of analysis.

[clnq]

It has greatly demotivated me to learn that productivity was measured by commit count in one of the companies I worked in. Interestingly, I was the most "productive" engineer there at the time. Yet my code was garbage (no offence to garbage intended). This oxymoron showed me that there's no path for me to improve in that company and I soon left.

[ryandrake]

Nothing is just a discrete piece of data. If it even barely feeds into something that feeds into something that feeds into something that feeds into something that affects developers’ compensation, then it will get gamed.

[jacob019]

This sounds reasonable. A lot of oppinions being presented in this thread like moral truth.

[admax88qqq]

It's a decent metric until you start to use it as a metric. Like most numeric measures of productivity I guess

[scubbo]

One of my favourite eponymous laws! https://en.wikipedia.org/wiki/Goodhart%27s_law