Comment by a-priori | Hacker News Reader

Comment by a-priori | Hacker News Reader

One of the important lessons you need to learn is that code is a liability not an asset! All else being equal, from a balance sheet perspective having more code puts the company in a worse situation.

Your job as a software developer is, roughly, to deliver maximum business value with minimum cost, and that includes writing minimum code to accomplish the task. That is what the senior developers are talking about when they're saying you've written too much code.

It does sound to me like they've got a well designed system if you can add new features simply by making a small modification and some configuration to the existing code. As long as it's also well tested and well documented (that may be lacking...), you've got the ideal codebase: one in which you can add large amounts of business value with only incremental changes.

You mention that this is "great for the business but not much fun for me". I think this is a sign of inexperience. Part of what makes something fun is how difficult it is. If something is too easy it's boring; if something is too hard it's frustrating. In the middle we find things fun. The reason writing lots of greenfield code is fun for you is because it's easy. Understanding and modifying existing code is harder, and that's currently too hard so you find it frustrating. You need to push past this stage to improve as a developer. As you get better, it will become easier to work in existing code and will stop being so frustrating.

> One of the important lessons you need to learn is that code is a liability not an asset

I cannot upvote this enough.

This is simply not true. If code was an liability, it would be profitable to transwer owenership of it to other people. I haven't noticed any software company doing that.

Maybe not what you meant, but I immediately thought of SaaS. Or various companies' policies of open sourcing non-core software.

Both of those are along the lines of "I need code to do this thing, but I don't want to be the (sole) maintainer."

You could write your own language, IDE, OS, build system, source control, networking library, logging library, shopping cart, payment processor, etc.

That's an overly pedantic use of the word "liability." It simply means that all things being equal, it is better to do $THING in 50 lines of code than it is to do it in in 500.

This is easy to explain when you treat third parties as liabilities as well. For many companies this is a bigger liability than maintaining the code in house.

I recently made the decision to have a third party build a component as opposed to doing it in house. The cost and time to build a component in house vs using a third party ended up being a wash, but the third party offered to maintain and support a solution so this presented less risk to us. This major risk we incurred was in vendor lock-in.

These types of trade offs happen all the time. Think about virtually any SAAS offering that could otherwise be built in house.

In software, there's a whole industry around this: we call it SaaS and/or cloud services. And in fact, it's basically what it means to be a 'services' company. Your customers are paying you to move that liability I mentioned onto your balance sheet instead of theirs.

A junior dev I worked alongside a few years back got quite angry with me when we were facing an "interesting" problem - he was well into thinking how he would write code to solve the problem meanwhile I had googled and found an existing utility downloaded it and demonstrated that it worked - 0 lines of code required....

[NB To be fair I had the same sense of disappointment myself years before when I was quite proud of a package to do CLOS object persistence and a more experienced chap told me there already was something to do that...]

Great comment. It's a bit hazy when you say that code is a liability and also that they've got an ideal codebase because you can add value easily due to the existing code. Maybe something more like: "new code is a liability, and tested, extensible code is an asset."

In this metaphor, all code (new or old) is a liability and the revenue/value stream derived from it is the asset. As a developer, you're trying to maximize assets minus liabilities. It's okay to take on a liability as long as it's balanced by a greater asset.

But buying on margin increases your volatility and risk exposure, so you shouldn't take on more than you need to. Assuming zero transaction costs, it's always a good idea to substitute less code for the same benefit.

The first paragraph is just plain wrong. Code is an asset.

Edit: Nice to have a comment downvoted, even though what I said is true.

It's kind of like conventional depreciating capital assets like buildings. A building requires maintenance, utilities, taxes, repairs and so on. If your building is too large for your needs, the costs can become a debilitating albatross round the neck of the business. There have been plenty of European aristocracy bankrupted by having a house that was too big.

In programming terms, it's very tempting to say, "this room is untidy, I'm going to build a new one." It's certainly more fun than tidying your room. But this is how you get sprawl and bloat.

Well, you can simply give up ownership rights on the code. If code was indeed a liablity, it would be profitable to transfer ownership to (for example) me.

You can give away your castle with a license indicating that nobody can keep you out, too, but that doesn't guarantee that it will be maintained so that you can keep using it, either.

You're being downvoted because while you were technically correct you completely missed the point and your comment adds nothing to the discussion. But at least you got the satisfaction of "correcting" somebody, eh?

I got that he was trying to say something along the lines of "more code = more maintanance"... but code is simply not a liability. (Yeah, I have a natural urge to correct stuff that's incorrect, but that's not an uncommon trait.)

Reply on news.ycombinator.com