Hacker News Reader

Comment by startupsfail | Hacker News Reader

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.)

View on HN

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.

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.

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.

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

I reckon I could count the counterexamples on one hand.

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.

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.

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.

Reply on news.ycombinator.com