Hacker News new | past | comments | ask | show | jobs | submit login

>In the real world with limited resources, limited skills, limited budgets and limited brain power, yes code is a liability.

That's an unbalanced conclusion. Code can be a liability but it can also be an asset.

Do we have limited resources? Maybe writing new code can help. E.g. In cars, the electronic fuel injectors have computer code determining the optimal amount of gas to inject to minimize fuel usage. Fuel efficiency is improved over older "non-computer-code" carburetors. Computer code is an asset that's equivalent to discovering new proven oil reserves.

How about the limited resource of bandwidth on networks? Code and algorithms like h.264/h.265 that shrinks video enough to make it practical to stream to homes maximizes the existing network without having to lay a bunch of new fiber optic cables to every house.

And consider all these YC companies that aren't worth much today. How do they become more valuable? They need to write more code. New features that customers find valuable requires coding. Even if the startup's code does not have patents, it will still be part of the tech portfolio assets that the acquiring company will include in the purchase.

The "code is a liability" seems to be true if one limits their focus to negative situations like npm leftpad and the Boeing MCAS accidents. In contrast, I don't think the astronauts thought the Apollo Guidance Computer was a liability if it helps them get to the moon.

Code may be necessary to write software, but it's still a liability. All else being equal, accomplishing a task in n lines of code is worse than accomplishing it in n - 1 lines.

That's where those aphorisms come from. No code runs faster than no code! No code has fewer bugs than no code! No code is easier to understand than no code!

We all know that. We are not arguing with that. We all understand that code is always written to solve a problem or make something more efficient, or create a new functionality. In that way it is most of the time an asset. That is a given. What we are talking about is a higher-level view which you get from a lot of experience in big codebases and big projects, in which code is almost always also a liability. It means that when you write a piece of code, the wise thing to do is to always assume that it will be a liability (in addition to all the wonderful things it does) to someone, in some situation, in some time. That way one can easier think through all the ways this liability can show itself, and thus somewhat mitigate those ways. Returning to original topic, choose a stable mature language/system which a lot of programmers know, instead of a new shiny one (even though the shiny one might be 5% more efficient in lins of code or something) - is a great way to reduce the liability surface in the future.

> That's an unbalanced conclusion. Code can be a liability but it can also be an asset.

maybe that's why he said:

> Not only a liability, but a liability among other things.

>maybe that's why he said: > Not only a liability, but a liability among other things.

It was my mistake then and I misinterpreted "among other things" to mean : "Code is not just a liability but it's a liability among the other things I just listed like limited resources and limited brainpower" instead of "Code is a liability among other things I won't say explicitly like code also being an asset".

Because I interepreted it the 1st way, I wanted to emphasize the opposite view: that limited brainpower is why code can be an asset to relieve humans from mundane boring calculations to redirect that precious brainpower to higher level creative thinking. Limited resources also motivates new code that can be an asset to expand those resources.

I can understand being confused by that wording, it wasn't the greatest. :)

Code is a liability; functionality is an asset.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact