You’re describing people who believe that code is an asset, when the reality is that it’s a liability: zero lines of code would be ideal if you could get away with it, but you can’t, so you have to compromise and limit that liability as much as possible by minimising the amount of code and relentlessly keeping it simple, easy to read, etc. Perhaps they’d be more sympathetic to your perspective if you framed it that way?
The whole "code is a liability" mantra needs challenging IMO - it's too simplistic and "cargo culty". It's a misappropriation of a financial accounting term (where Assets = Liabilities + Equity) and liability also carries with it all kinds of negative associations.
It has a value in making businesses aware that production code has an operational cost just to keep it "alive". And it's useful for tempering junior developers who haven't yet absorbed principles like KISS and YAGNI.
But it fails to factor in the relation between code and an organisations ability to make (or save) money from that code. For example the capabilities of your code may be a competitive edge for your business. 10 lines of code which uses CPU and memory inefficiently may end up being more expensive than 1000 lines of code which uses CPU and memory _efficiently_ and leads to lower infrastructure costs as usage grows.
As far as I'm aware the term goes back to 2007 - https://web.archive.org/web/20070420113817/http://blog.objec... - a time where businesses hadn't really understood how to manage software based businesses, so it was a useful concept to help management become more mature about how they think about software.
But these days knowledge of how to run software based businesses is far more widespread - we don't need to simplify our thinking to "code is a liability".
Leverage is a combination of an asset and a liability. You gain assets in the short term in exchange for a long term liability.
There is a difference between code and a liability. If a business could wave a magic wand and instantly remove all liabilities from the balance sheet, it would do so without question. They would not, however, do that for code (or the business would collapse).
Something like: software is an amalgamation of the desirable capabilities it provides, which are assets, and the code itself which must be maintained and as such is a liability. Complex and convoluted code represents a greater liability.
Part of your job as a commercial software engineer is to maximize the balance sheet of the projects you work on.
Yeah but then they just argue with you about whether it's simple. There's a certain kind of person who loves taking complex things and calling them "simple".
True enough. I think when we say “simple” we often really mean “cheap” (to maintain), so maybe it’s better to cut to the chase and just say that instead.
it's more often that they don't understand what simple means for most people
For example they might think that in a mixed-paradigmatic language the "pure
functional approach" is more simple even if it introduces more indirection and
requires a deep understanding of various more advanced language constructs(*).
Or that the simplest explanation of monad is the one based on PL-theory instead of an explanation based on terms people without an scientific-PL background are more familiar with.
Or people which think that writing down things in predicate logic is just way simpler then writing them down in English (well, I guess thats somewhat me).
None of the "I find this is simpler" points I mentioned are bad, but not realizing/accepting that what is simpler for you isn't simpler for others is the problem.
Rich Hickey has an excellent talk "Simple Made Easy". He points out that "simple" and "complex" describe objective properties. The terms are often (incorrectly) used interchangeably with "easy" and "hard", which are subjective.
Though code is an asset as well... Just not as valuable as people might think. Code is not a liability if it is not used, the liabilities come from production usage.
I agree with what you mean, but I’d nitpick and say it’s not the code itself that’s the asset, but rather the behaviour of that code when executed. If you could refactor and get the same behaviour with less code (whatever that means), that’d be a net win, right? So the quantity of code is making a negative contribution.
I consider code to be a liability, and Git history to be an asset. If something's in version control, there's no need to keep unused cruft around "just in case" it's useful in the future.
what a load of crap, you mean linux kernel is a liability. this is typical thinking of folks who are removed from technical work & just consider development as 'cost'. Code & development history is an asset because it stores the time-series sum total of development decisions to get to this point. keeping it readable I can understand but pointlessly minimizing it without the bigger understanding of what it serves because .. 'hey it works' is trivializing it a bit.
