Hacker News Reader

Comment by karlb | Hacker News Reader

Two more quotes about this subject:

Jeff Atwood: “the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options.”

Robert Galanakis: “The fastest code is the code which does not run. The code easiest to maintain is the code that was never written.”

View on HN

A father of these being, as usual Dijkstra: in his EWD1036-28 "On the cruelty of really teaching computing science" (1988-12-02) he notes

> it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

(emphasis mine)

Though of course "lines of code" in Dijkstra's essay is itself only a proxy, a line of Java code and a line of Perl code have fairly difference costs.

I do not think a product with zero lines of code is always better than a product with 10,000. So there is obviously some metric that goes up with lines of code but goes down with bugs and technical debt.

Sometimes the downswing from a single line is so dramatic, that such maxims are expressed... but don't take them too literally. Let's be real here.

Which is why Dijkstra's take on it is excellent: the LOCs you write are a liability. Incurring liabilities is normal, but your goal isn't to maximise liabilities.

That might be a good way for engineers to think of it, but you don't really want managers to see programming as a liability, because then they start thinking in terms of eliminating liability for business productivity (i.e. killing your job, not investing money to let you do your job effectively, etc).

There's already enough problems with companies considering their tech departments to be "cost centers" that don't result in direct revenue generation, therefore they don't respect the department enough, we don't need them thinking we're completely undesirable.

But it is a liability. If your business could generate the same revenue while spending less resources maintaining internal technology, you'd do it in a heartbeat.

No, tons of stuff are liabilities that they don't remove. Rent, salaries, etc.

I don't really get what this "cost center" thing gets you at all. Suppose you make televisions. R&D is a "cost center". Whoever's in charge of sourcing components is a "cost center". Hell, making the damn TVs is a "cost center". In fact, the only thing I can think of that isn't a "cost center" is sales. But without everything else, sales would have nothing to sell.

So what the heck is the point of labelling things "cost centers"?

Oh, came on. Of course you sometimes want code.

You spend lines of code, to get functionality. Keep your expenses down, but nobody is saying they must be zero.

Think of lines of code as surgery to excise a tumor.

Of course you want to remove the tumor. Curing cancer is the goal. But each surgery is a liability; each scalpel cut you make may bring potentially fatal complications, so you strive to perform as few surgeries as possible while still saving the patient.

Rewarding LOCs is like rewarding the high number of surgeries a doctor had to perform on a patient in order to save him/her. It's backwards!

In the same way, spending $0 is not always a better choice than spending $10,000. You're spending the lines of code with the hope that your return on investment makes the liability worth it.

I like Bill Gates' quote "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."

These are the clever quip advice that I know and understand but can never really use. Clever, but completely and hopelessly useless to me.

To get better at coding, I have to be prolific with writing code. Prolificity doesn't have to mean verbosity. Be prolific but do it succinctly. Code like Hemingway wrote.

(The irony in this post is apparent to me, thanks.)

>Robert Galanakis: “The fastest code is the code which does not run. The code easiest to maintain is the code that was never written.”

Obviously that has limits, else the best MVP would be empty space.

It didn't say the best product. It said "fastest" and "easiest to maintain" code, which are only two of hundreds of factors for success. Many of which are not code related.

Well, technically (or even theoretically I'd venture), empty space is the best MVP of all time. :p It required no code (baring any metaphysical interpretations of the term) and it still functional to this day. :p

MVP doesn't have to involve custom code (or any code at all for that matter). See most startup landing pages or kickstarter for example which test interest in an idea

An interesting analogue exists in the academic world -- an advisor's most important job is to guide you on what you should not do or attempt.

Reply on news.ycombinator.com