Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

-2000 Lines of Code (2007)

folklore.org

Post reply on HN
Print view View original

211–220 of 222 posts

Re: -2000 Lines of Code (2007)

#211

Post by bcrl »

Taniwha wrote: post #195
Taniwha wrote: post #194

Earlier quoted context omitted.

I think it started out in ROM, it has low core jump vectors so that portions can be replaced (rather than just the whole thing) I worked designing Mac graphics accelerators back in the day, we hooked them up by replacing bits of QD through these vectors. So over time rom fixes got made and some of it would have come off of disk If you follow that second link you'll find a zip file with quickdraw source in it, you'll…

Also putting display core routines in ROM was important because RAM access was slower (because the display used 1/2 the RAM bandwidth)

Good point. The Amiga did the same thing in the Amiga 500 and 2000. The Amiga 1000 would have if the operating system had been more stable at time of release. It also saved a significant chunk of RAM as the 1.x releases of AmigaOS used 256KB ROMs while 2.x on were 512KB ROMs.

Re: -2000 Lines of Code (2007)

#212

Post by talsperre »

zac23or wrote: post #91

Counting lines of code as a production metric is very stupid. I remember solving an unsolvable 20 years old bug with a line of code, another 3 years old with a order by. How to measure the impact of a line of code? And in my experience, bad programmers write a lot more code... I will never forget the story[1] of a Microsoft developer rewriting a piece of IBM code that had 33 thousand characters, after rewrite ... 220…

In my opinion, there is still some relation between LoC and engineering output over a long period of time. Some of the greatest computer scientists and engineers have insane code outputs and I believe it does directly translate into impact in some ways. The issue is when Loc becomes a metric to measure performance. At that point, we have an instance of Goodhart's Law: “When a measure becomes a target, it ceases to be a good measure.”.

Re: -2000 Lines of Code (2007)

#213

Post by drpixie »

praptak wrote: post #16

The largest impact is sometimes asking simple questions (how are you going to handle X?) which leads to not building something. When this something hasn't ever had a chance to work, you saved the whole cost of trying to build it. This is not only impossible to measure as a numerical metric but also makes you enemies. Kudos to those who dare to do that anyway.

When I managed software for a large corporate, I kept a box of pencils on my desk.

For around 1/2 the information requests that came through the department (always very important, we need the info now, it will save/make big dollars) the obvious answer was "Work it out from the info you already have. You've got a calculator and spreadsheet - would you like a pencil?"

Better to avoid the system handling X than having multiple special cases bulking up the systems, most of which only get used once in a blue moon. No one knows the special cases/programs are there, or what actually do. Even if well documented, no one spends the time required to know what's available. So most of those special features are actually waste of time.

Re: -2000 Lines of Code (2007)

#214

Post by rightbyte »

barcist wrote: post #202
bdw5204 wrote: post #101

Earlier quoted context omitted.

Using production metrics as a whole is very stupid and a good way to get devs to optimize for the metrics rather than quality work. A contemporary example would be a company that promotes for "impact" (i.e. launching new products) which is a great way to have a bunch of failed products that nobody maintains!

The trick is to align the metrics with company goals. It's not easy, but not impossible either. For example, if quality is your goal, then the metric you give your devs is "number and severity of bug reports coming in from customers". If unsatisfied feature requests are part of that number, then the devs have to strike a balance between churning out features and preventing bugs (and fixing discovered ones). Obviously…

Ye and you end up with blame games and hot potatoes being passed around.

Bug count metrics incentives "don't touch anything" and coding with feuture flags and globals to limit the scope of change and circumvent the architecture.

Like, just don't do metrics and have the management actually review the work of their subordinates if that is important to follow up on. Actual management can't be compressed to a acting on some scalar values.

Re: -2000 Lines of Code (2007)

#215

Post by Double_a_92 »

helpmefindpurp wrote: post #159
pixl97 wrote: post #114

Earlier quoted context omitted.

It's terrifying working around fintec and seeing how many 20MLOC monoliths are laying around and the code quality issues that crop up in them.

This is cope. those applications are there because they work. Mistakes in "20M LOC monoliths" are exceedingly rare in the financial world. Look how bad "hipster" software is in comparison! Billions in profit means billions in quality

The problem is not that they don't work, it's that they can't ever be touched again because it's impossible for anything to understand the code.

Re: -2000 Lines of Code (2007)

#216

Post by michaelcampbell »

rsynnott wrote: post #185
michaelcampbell wrote: post #181

Earlier quoted context omitted.

For you, maybe; but to your parentposter's point, it is measured not because it is useful to the overall org, but because it is easy to measure. In that sense, it's a great KPI, when the measurer (presumably some middle management) considers it an indicator of performance. It's just that you and they define "performance" differently. It's perverse incentives all the way down (or, perhaps, up).

I mean, sure, if you have a sufficiently bonkers view on performance metrics, then, say, index finger diameter could be a performance metric, but in terms of things which could actually be seen by any reasonable person as a KPI, lines of code ain’t one.

> any reasonable person as a KPI

Have you MET middle managers in the wild? As I said, most of these metrics are measured because they are easy, not because they are useful. The incentives at that level are to come up with some sort of metric and browbeat people into making it; the incentives for the browbeaten are then to make the number. Doesn't matter what the number means.

Re: -2000 Lines of Code (2007)

#217

Post by helpmefindpurp »

Double_a_92 wrote: post #215
helpmefindpurp wrote: post #159

Earlier quoted context omitted.

This is cope. those applications are there because they work. Mistakes in "20M LOC monoliths" are exceedingly rare in the financial world. Look how bad "hipster" software is in comparison! Billions in profit means billions in quality

The problem is not that they don't work, it's that they can't ever be touched again because it's impossible for anything to understand the code.

The people looking at them just lack the skills...

Re: -2000 Lines of Code (2007)

#218

Post by yunwal »

khazhoux wrote: post #173
peteradio wrote: post #109

Earlier quoted context omitted.

At the end of the day nothing about the number of commits was used in your thoughtful analysis, it was only the contents of the commits which you attribute any value.

Yes and no. Certainly I know lots of great developers who prefer to commit work frequently and incrementally, others who do slower bigger changes. But I don't think I know any engineers who can create a substantial amount of software with only infrequently and tiny changes. I encourage you to look at the code produced by whoever you think is the top engineer in your team or company (and I'm talking only about the eng…

> Now look at the code by that one person who you know isn't pulling their weight and who you think isn't getting much done.

This is bad, but it’s not the worst type of engineer. The worst engineers often have huge deltas and can kill companies singlehandedly.

Re: -2000 Lines of Code (2007)

#219

Post by mehdix »

jpc0 wrote: post #208
mehdix wrote: post #49

Earlier quoted context omitted.

I was giving myself RSI by deleting what was happening) and Can feel you right there.

> when I reverted to using regex Begrudgingly I hope... If you replaced 4000LoC with a regex that regex scares me...

haha! I did use regex to find and delete repetitive patterns of code with slight variation that would be carried out by the aforementioned function.

I wish I could write such a monstrosity though :)

Re: -2000 Lines of Code (2007)

#220

Post by renox »

michaelcampbell wrote: post #175
datavirtue wrote: post #103

Earlier quoted context omitted.

If Einstein was pressured by metrics we would have never heard of him.

I suspect he was... as a patent clerk. And that may be why we never heard of him THEN.

> I suspect he was... as a patent clerk.

I believe he managed to work on patents only in the morning..

Post reply on HN