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

Algorithms we develop software by

grantslatton.com

Post reply on HN
Print view View original

61–70 of 108 posts

Re: Algorithms we develop software by

#61

Post by throwaway87483 »

stanac wrote: post #44
andsoitis wrote: post #13

Earlier quoted context omitted.

A project manager or bizdev person writes, rewrites, and rewrites again the document they produce do they not? Or do they write the perfect document at first go?

Worst kind of jira ticket is just a link to a document that can be edited anytime. In that case I just replace the link with a new link pointing to the fixed version of the document and inform the author of the ticket/document about it.

Depending on what kind of document it is, I often resort to extracting its contents with pandoc by converting it into markdown, and then replacing the original description. Makes search work properly too.

Re: Algorithms we develop software by

#62

Post by dataflow »

mempko wrote: post #60
dataflow wrote: post #54

Earlier quoted context omitted.

> You would obviously test the software before it goes to the users That... is literally what unit tests do. Test the software before you give it to users. You seem confused what the debate is over. Nobody is arguing against contracts. They're awesome. They're just not substitutes for unit tests (or vice versa for that matter). You guys have been arguing against unit tests , which is an absurd position to take, hence…

It's not absurd. Unit test are expensive and slow you down while at the same time not targeting the part of software where bugs occur. It's usually HOW functions are composed that cause bugs, not the functions themselves. Contracts rest the interaction of components while unit tests don't.

This is definitely absurd... but okay, riddle me this then. Say you're reimplementing string.indexOf(string) with your fancy new algorithm so you can deliver a nice speed boost to users. How do you do your best to minimize the chances of it blowing up on everyone without writing unit tests?

Re: Algorithms we develop software by

#63

Post by smusamashah »

hintymad wrote: post #48

I remember seeing somewhere a popular list of top 10 algorithms used in systems, and it's kinda depressing to realize that the most recent algorithm on the list, Skip List, was invented roughly 30 years ago, and every single one of them was taught in an introductory data structure course. That is, we most likely do not need to study the internals of algorithms nor need to implement them in production. For such a long…

Did you read the article?

Re: Algorithms we develop software by

#64

Post by pkoird »

A good code, in my opinion, is written by appropriate selection of suitably contained abstractions. The problem with this, and the article does try to talk about it, is that for you to select appropriate abstractions, you need to know the "entire" thing. Which is to say, you need to have a knowledge of something that isn't there yet.

In other engineering disciplines like say civil or architecture, this problem is solved by using a good blueprinting paradigm like CAD layouts, but I find a distinct lack of this in software[1]. Ergo this advice which is a rephrasing of "know first and build later". But it is also equally easy to lose oneself in what's called an analysis paralysis i.e. get stuck in finding the best design instead of implementing a modest one. In the end, this is what experience brings to table I suppose, balance.

[1]closest I can think of are various design diagrams like the class diagrams etc.

Re: Algorithms we develop software by

#65

Post by mempko »

dataflow wrote: post #62
mempko wrote: post #60

Earlier quoted context omitted.

It's not absurd. Unit test are expensive and slow you down while at the same time not targeting the part of software where bugs occur. It's usually HOW functions are composed that cause bugs, not the functions themselves. Contracts rest the interaction of components while unit tests don't.

This is definitely absurd... but okay, riddle me this then. Say you're reimplementing string.indexOf(string) with your fancy new algorithm so you can deliver a nice speed boost to users. How do you do your best to minimize the chances of it blowing up on everyone without writing unit tests?

First, users don't use string.indexOf(string). Users use software that uses string.indexOf(string). Second, I would write a test that takes generates a variety of inputs to cover the domain of string.indexOf(string) and have it call the old version and the new version. I would then collect stats around the performance of each call and make sure the new implementation is faster by the threshold I meant for it to be. Since the PURPOSE OF THE REFACTOR WAS PERFORMANCE. Then I would delete the test after I'm satisfied it worked well on the target hardware, etc.

Let's look at the chrome unit tests.

https://chromium.googlesource.com/v8/v8/+/3.0.12.1/test/mjsu...

This test checks one case and then does a loop over to make sure various sizes work. This is a POOR test because it doesn't cover the domain of the function and exceptional cases. This test is pointless to have and run every build. Why keep it, it does nothing useful.

My point is that if you are refactoring a function, you are going to have to write a NEW TEST anyway because the purpose of a refactor is different each time. The old tests are going to be useless. This is why contracts are so useful because they will ALERT YOU when the software does something you didn't assume. Unit tests don't do this.

From an information theory perspective, the old tests would not provide you with new information. If you want to make sure your refactor works like the old function, then compare the outputs of your new function with the old one over the domain of the function. Then if it's good, delete the tests because why keep them.

Experience shows that users will do things to your program you did NOT expect and therefore your tests will not cover. And more likely than not, refactoring requires rewriting tests anyway so the old tests are usually always useless.

Now SYSTEM tests ARE useful. Tests that wire up many components and test them are useful. But a UNIT test, which tests one function is often just a waste of time to keep.

Re: Algorithms we develop software by

#66

Post by nkozyra »

jackcviers3 wrote: post #21
mempko wrote: post #11

Earlier quoted context omitted.

Unit tests are a waste of time. Design by Contract + system tests are a far superior technique that take less time and find more bugs.

The last comprehensive study I read indicates that they improve internal and external code quality by 76% and 88% respectively while reducing productivity some[1]. If you have papers that indicate your claim I'd be interested in reading them or in ones that refute the metastudy linked below. 1. https://doi.org/10.1016/j.infsof.2016.02.004

TDD and using unit tests are not the same thing, though.

I'm very much a TDD sceptic, but believe unit tests have a place.

Re: Algorithms we develop software by

#67

Post by nkozyra »

jrvarela56 wrote: post #40
edflsafoiewq wrote: post #24

Earlier quoted context omitted.

The second time doesn't cost as much as the first.

And the first is cheaper than a ‘regular single version’ bc you build it with the thought that you will throw it away.

You throw it away but in truth much of it survives in a much better design.

Re: Algorithms we develop software by

#68

Post by ww520 »

I usually won't rewrite the whole thing twice, but would rewrite parts of it multiple times. For the very least, the second time around I would format things and add comments to make things easier to be understood. Code should be written for comprehension.

Re: Algorithms we develop software by

#69

Post by dataflow »

mempko wrote: post #65
dataflow wrote: post #62

Earlier quoted context omitted.

This is definitely absurd... but okay, riddle me this then. Say you're reimplementing string.indexOf(string) with your fancy new algorithm so you can deliver a nice speed boost to users. How do you do your best to minimize the chances of it blowing up on everyone without writing unit tests?

First, users don't use string.indexOf(string). Users use software that uses string.indexOf(string). Second, I would write a test that takes generates a variety of inputs to cover the domain of string.indexOf(string) and have it call the old version and the new version. I would then collect stats around the performance of each call and make sure the new implementation is faster by the threshold I meant for it to be. S…

Honestly... I can see it's going to be genuinely exhausting for me to rebut point-by-point here, so I'll just let others read this and continue if they're interested. I really appreciate the response though, at least it explains your thought process well.

I have one question for you that I feel I have to ask: have you actually practiced commercial software development on a team (say, 5+ developers on the same codebase) in this manner that you describe for a significant period of time (say, 2+ years)? and if so, do you feel the resulting software has been robust and successful?

Re: Algorithms we develop software by

#70

Post by bckr »

bdw5204 wrote: post #55
andsoitis wrote: post #13

Earlier quoted context omitted.

A project manager or bizdev person writes, rewrites, and rewrites again the document they produce do they not? Or do they write the perfect document at first go?

If I'm writing something, I'm writing it once. That "prewriting" stuff they teach in schools just slows down the process and makes you overthink your choice of words. I take the same "1 take" approach with code with the idea being to write the best solution on the first try. Why waste time writing something bad just so you can fix it later? That doesn't make any sense. As I'm writing, I do go back and make changes as…

1. You don’t take any notes or make any bullet points?

2. > As I'm writing, I do go back and make changes as they pop into my head

This contradicts the idea that you only write once.

3. You don’t get feedback on your first finished version and make changes?

Post reply on HN