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

Fast software is a discipline, not a purpose

lemire.me

Post reply on HN
Print view View original

51–60 of 68 posts

Re: Fast software is a discipline, not a purpose

#51

Post by hasenj »

zimpenfish wrote: post #48
hasenj wrote: post #41

Earlier quoted context omitted.

This quote is so misunderstood and so abused all the time. The point of the statement is to not micro-optimize this and that corner of the program without having any data to guide you on what you should optimize and how. It's not a rallying call to forgo all concerns about application performance and efficiency. The mis-application of this quote is the root of all evil in modern software IMO. It's why a chat program…

> 1. Make it work correctly and efficiently (to a reasonable degree) Unfortunately, this took your team 6 months and the people that launched their app 4 months ago (having opted for "make it work") now have 90% of your market and you've all just been made redundant because the customers do not care whether your app is "more correct" and "more efficient" because they just plain damn couldn't use it. There's a reason…

There's no evidence than any of this is true.

First market is not often the winner. Facebook came very late to the social media scene but it dominated.

Google came very late to the search engine scene, and people don't even remember this but there was a time when there were a ton of search engines and anyone at the time would probably think that the search engine market is saturated and there's no space for a new product.

All evidence actually points to better products dominating the market even if they come late.

If your competitors released their app 4 months ahead of you but it was full of bugs and always hangs up, and then you release your product which actually works and performs well, people will see your product as a breath of fresh air.

Another example is the Chrome browser, which came at a time when Firefox and IE were competing fiercely for market share, and Chrome completely dominated them on the simple basis that it was _really fast_.

For most products it doesn't even cost 6 months to make it fast. If you have that as a goal from the very start, there will never be a stage of "omg it's really slow let's try to make it a bit faster". It will always just be fast.

Re: Fast software is a discipline, not a purpose

#52

Post by srean »

jackjeff wrote: post #2

“Avoid multiple passes over the data when one would do.” Totally disagree. Unless performance is an issue (like I’m not dealing with a trivial number of elements), I would rather use functional programming approaches to sort data into shape (think map/filter/reduce). These approaches typically result in passing over the data multiple times, and often performing multiple copies, but it makes for readable and less erro…

> Totally disagree.

Hmm, I see....

> Most collections/array I process have trivial number of elements (Ah! ok that explains it.

> I would rather use functional programming approaches to sort data into shape (think map/filter/reduce). These approaches typically result in passing over the data multiple times, and often performing multiple copies,

That's a good recommendation. If you tend to write in a deforestable style (whether deforested automatically by the compiler or, by you manually) you can mitigate some gratuitous copying and multiple passes.

Re: Fast software is a discipline, not a purpose

#53

Post by a_imho »

There is a reason we don’t tend to hire people who show up to work in dirty t-shirts. It is not that we particularly care about dirty t-shirts, it is that we want people who care about their work.

I don't quite agree the cleanliness of clothing is a good proxy of one's craftsmanship or personality, even if t-shirts are acceptable garment at a particular workplace.

Re: Fast software is a discipline, not a purpose

#54

Post by hasenj »

zimpenfish wrote: post #49
Cthulhu_ wrote: post #40

Earlier quoted context omitted.

The challenge there is that a lot of developers are pushed by their managers to go to the next feature after #1, postponing 2 and 3 for when there's time. Time to market is considered the most important thing. Of course, it accumulates after a year.

> pushed by their managers to go to the next feature Understandable, though, since features are what get customers to pay - 99% of customers will not care about efficient code as long as they can achieve what they're after without screaming.

Things that are full of bugs and are sluggishly slow are what makes customers scream their lounges out 99% of the time.

Re: Fast software is a discipline, not a purpose

#55

Post by tomtomau »

zimpenfish wrote: post #47
ssijak wrote: post #45

"When people train, they usually don’t try to actually run faster or lift heavier weights. As a relatively healthy computer science professor, how fast I run or how much I can lift is of no practical relevance. " This is really strange. If you don`t try to lift heavier weights you will not have progress. It is called progressive loading. I don`t wan`t to go into the details of the training, but if you do not track an…

> If you don`t try to lift heavier weights you will not have progress. That depends on what you're aiming for - if you're aiming for tone rather than bulk, you'd go for more reps of the same weight rather than stepping up the weight with the same reps, wouldn't you? (Although I guess, technically, that does count as "heavier" since you're still moving more weight in your sets.)

The general consensus is there's not really such thing as 'tone' - usually that's just a matter of low bodyfat % which shows your muscles more promimently.

What you're talking about somewhat though is balancing hypertrophy and strength goals - where someone may wish to increase their reps to say 8-20 which is demonstrated with studies to increase muscle size, but is poorer for progressing with strength (where 3-8 reps is more effective)

Re: Fast software is a discipline, not a purpose

#56

Post by delta1 »

cjsuk wrote: post #42
delta1 wrote: post #26

1. Make it work 2. Make it right 3. Make it fast "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet w…

1. Make it work 2. Make it ... err actually fuck it, let's build a hairball on top of it. That's how it really rolls. You have to think it fast, think it right, then make it work because if you do it the other way round, it never happens.

You're conflating management and priority issues with programming issues.

Re: Fast software is a discipline, not a purpose

#57

Post by [deleted] »

hasenj wrote: post #41
delta1 wrote: post #26

1. Make it work 2. Make it right 3. Make it fast "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet w…

This quote is so misunderstood and so abused all the time. The point of the statement is to not micro-optimize this and that corner of the program without having any data to guide you on what you should optimize and how. It's not a rallying call to forgo all concerns about application performance and efficiency. The mis-application of this quote is the root of all evil in modern software IMO. It's why a chat program…

[deleted]

Re: Fast software is a discipline, not a purpose

#58

Post by cjsuk »

delta1 wrote: post #56
cjsuk wrote: post #42

Earlier quoted context omitted.

1. Make it work 2. Make it ... err actually fuck it, let's build a hairball on top of it. That's how it really rolls. You have to think it fast, think it right, then make it work because if you do it the other way round, it never happens.

You're conflating management and priority issues with programming issues.

The two are intertwined and inseparable.

Re: Fast software is a discipline, not a purpose

#59

Post by zimpenfish »

hasenj wrote: post #51
zimpenfish wrote: post #48

Earlier quoted context omitted.

> 1. Make it work correctly and efficiently (to a reasonable degree) Unfortunately, this took your team 6 months and the people that launched their app 4 months ago (having opted for "make it work") now have 90% of your market and you've all just been made redundant because the customers do not care whether your app is "more correct" and "more efficient" because they just plain damn couldn't use it. There's a reason…

There's no evidence than any of this is true. First market is not often the winner. Facebook came very late to the social media scene but it dominated. Google came very late to the search engine scene, and people don't even remember this but there was a time when there were a ton of search engines and anyone at the time would probably think that the search engine market is saturated and there's no space for a new pro…

> but it was full of bugs and always hangs up,

That doesn't really fit in the "make it work" that I specifically mentioned. If you change the scenario, sure, things could be different!

Re: Fast software is a discipline, not a purpose

#60

Post by zimpenfish »

hasenj wrote: post #51
zimpenfish wrote: post #48

Earlier quoted context omitted.

> 1. Make it work correctly and efficiently (to a reasonable degree) Unfortunately, this took your team 6 months and the people that launched their app 4 months ago (having opted for "make it work") now have 90% of your market and you've all just been made redundant because the customers do not care whether your app is "more correct" and "more efficient" because they just plain damn couldn't use it. There's a reason…

There's no evidence than any of this is true. First market is not often the winner. Facebook came very late to the social media scene but it dominated. Google came very late to the search engine scene, and people don't even remember this but there was a time when there were a ton of search engines and anyone at the time would probably think that the search engine market is saturated and there's no space for a new pro…

> Chrome completely dominated them on the simple basis that it was _really fast_.

It isn't that simple - a lot of Chrome's success came because they "made it work" in ways that Firefox (horribly wasteful of CPU, memory, battery life) and IE (shambles in every department) didn't. Also helped in large part by having an enormous web monopoly pushing it and favouring it for their properties.

But you're definitely right that it came after them.

Post reply on HN