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

71–80 of 108 posts

Re: Algorithms we develop software by

#71

Post by bckr »

colechristensen wrote: post #3
from-nibly wrote: post #2

> "gun to your head, you have to finish in 24 hours, what do you do?" PSA: if you are a project manager / owner or some other similar position you do not get to ask this. This is a personal educational excercise not a way to get stuff done faster.

"gun to your head" is maybe not appropriate for work, but the exercise is good for cutting to the core of a task when necessary. It's really the same question as what is the minimum viable product.

How about “building is on fire” or “company is dead tomorrow”?

Re: Algorithms we develop software by

#73

Post by halfcat »

Dan Abramov talks about WET (write everything twice) [1] as generally a good approach, primarily because you often don’t know the right abstraction up front, and a wrong abstraction is way worse than a copy/paste.

He has some good visuals that illustrate how incorrectly dependent and impossible to unwind wrong abstractions can become.

[1] https://youtu.be/17KCHwOwgms

Re: Algorithms we develop software by

#74

Post by mempko »

dataflow wrote: post #69
mempko wrote: post #65

Earlier quoted context omitted.

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 codebas…

I've been doing this style of software development for 16 years (out of 28 years programming) across various projects.

If you want a small project that I wrote to look at, see henhouse https://github.com/mempko/henhouse. I wrote an article talking about design by contract and why it's better than TDD here https://mempko.wordpress.com/2016/08/23/the-fox-in-the-henho...

I've built a computer vision system that processed petabytes of data with only one or two bugs in production for any given year. At any given time we kept a bug list of zero. For the last five years I built a trading system using this same process. Again, we don't keep a bug list because if there were bugs, the system wouldn't even run. And if there is a bug we have to fix it immediately. We do have tests, but they are system tests. The worst bug we had that took too long to catch was in a part of the system that DIDN'T use contracts.

Design by Contract is a secret weapon people don't seem to know about.

Also see https://github.com/mempko/firestr, which I used Design by Contract extensively. It's a GUI program so the user can do crazy things.

Learn Design by Contract. Do system testing. Do exploratory testing. Do fuzz testing. Keep a bug list of zero. Don't waste time on unit testing.

If you are looking for popular software built using Design by Contract to various degree.

See SQLite (uses assertions heavily), .NET framework from Microsoft, Many of the C++ Boost libraries, Parts of Rust, Parts of Qt. The Vala programming language, Ada GNAT... and many others.

Here is a research paper from Microsoft that shows the advantage of contracts and code quality. https://www.microsoft.com/en-us/research/wp-content/uploads/...

Re: Algorithms we develop software by

#75

Post by dataflow »

mempko wrote: post #74
dataflow wrote: post #69

Earlier quoted context omitted.

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 codebas…

I've been doing this style of software development for 16 years (out of 28 years programming) across various projects. If you want a small project that I wrote to look at, see henhouse https://github.com/mempko/henhouse . I wrote an article talking about design by contract and why it's better than TDD here https://mempko.wordpress.com/2016/08/23/the-fox-in-the-henho... I've built a computer vision system that process…

I feel there's something missing in what you describe, and I'm trying to pinpoint what it is...

I can see it working if you have very few developers touching each piece of code, or if you get to exert control over the final application. But I don't see how it can work for large codebases or teams over long periods of time (read: large businesses)... especially not for library development, where your team is only responsible for providing library functionality (like string.indexOf(string) in my example, or matrix multiplication, or regexes, or whatever libraries do) and you don't necessarily even know whom the users are. There is no "system" or "integration" at that point, you're just developing one layer of code there, which is the library -- a piece of code responsible for doing just one thing. How the heck do you make sure arbitrary team members touching code don't end up introducing silly bugs over time, if not with unit tests?

Have you built any commercial libraries in this manner, rather than applications? i.e. where everyone on your team is jointly responsible for your library's development (like the implementation of string.indexOf(string) in my example), and other folks (whether inside or outside the company) are the ones who piece together the libraries to create their final application(s)?

Re: Algorithms we develop software by

#76

Post by aleph_minus_one »

> Another heuristic I've used is to ask someone to come up with a solution to a problem. Maybe they say it'll take 4 weeks to implement. Then I say "gun to your head, you have to finish in 24 hours, what do you do?"

Pretend to be capable of doing this, and in the short moment where the other person is not attentive, get the gun and kill him/her. This satisfies the stated criteria:

> The purpose here is to break their frame and their anchoring bias. If you've just said something will take a month, doing it in a day must require a radically different solution.

> The purpose of the thought experiment isn't to generate the real solution.

:-)

---

Lesson learned from this: if you can't solve the problem that the manager asks you for, a solution is to kill the manager (of course you should plan this murder carefully so that you don't become a suspect).

:-) :-) :-)

Re: Algorithms we develop software by

#77

Post by mempko »

dataflow wrote: post #75
mempko wrote: post #74

Earlier quoted context omitted.

I've been doing this style of software development for 16 years (out of 28 years programming) across various projects. If you want a small project that I wrote to look at, see henhouse https://github.com/mempko/henhouse . I wrote an article talking about design by contract and why it's better than TDD here https://mempko.wordpress.com/2016/08/23/the-fox-in-the-henho... I've built a computer vision system that process…

I feel there's something missing in what you describe, and I'm trying to pinpoint what it is... I can see it working if you have very few developers touching each piece of code, or if you get to exert control over the final application. But I don't see how it can work for large codebases or teams over long periods of time (read: large businesses)... especially not for library development, where your team is only resp…

I updated my original post with examples. I also included this research paper from Microsoft that shows a clear advantage of contracts and code quality. https://www.microsoft.com/en-us/research/wp-content/uploads/...

Note also types are a contract. TypeScript is basically introducing contracts at a high level to javascript.

Re: Algorithms we develop software by

#78

Post by vanjajaja1 »

> If, after a few days, you can't actually implement the feature, think of what groundwork, infrastructure, or refactoring would need to be done to enable it. Use this method to implement that, then come back to the feature

really good, this is key. building a 'vocabulary' of tools and sticking to it will keep your velocity high. many big techs lose momentum because they dont

Re: Algorithms we develop software by

#79

Post by dataflow »

mempko wrote: post #77
dataflow wrote: post #75

Earlier quoted context omitted.

I feel there's something missing in what you describe, and I'm trying to pinpoint what it is... I can see it working if you have very few developers touching each piece of code, or if you get to exert control over the final application. But I don't see how it can work for large codebases or teams over long periods of time (read: large businesses)... especially not for library development, where your team is only resp…

I updated my original post with examples. I also included this research paper from Microsoft that shows a clear advantage of contracts and code quality. https://www.microsoft.com/en-us/research/wp-content/uploads/... Note also types are a contract. TypeScript is basically introducing contracts at a high level to javascript.

> I updated my original post with examples.

Awesome, I'll dissect them and show you exactly where you're drawing the wrong conclusion ;)

> I wrote an article talking about design by contract and why it's better than TDD here

Nobody is advocating for TDD or disagreeing with that. Having unit tests != TDD.

> https://github.com/mempko/henhouse

So far as I can see, you're literally the only developer here -- which exactly illustrates my point. You can ignore a LOT of good engineering practices and be sloppy about a ton of things if you're the only developer (or one of a handful of developers), because hardly anything ever changes underneath you or without your knowledge. (Source: I've done it too.)

> See SQLite (uses assertions heavily)

SQLite has like... 3 developers? The vast majority, again, being 1 person. (I didn't even bother verifying your claim that they don't have unit tests, FWIW.)

> .NET framework from Microsoft

.NET absolutely has unit tests, here's one example: https://github.com/dotnet/runtime/blob/ebabdf94973a90b833925...

> Many of the C++ Boost libraries

All the ones I recall ever seeing have unit tests... which "many" don't? Here's one that does: https://github.com/boostorg/regex/blob/develop/test/regress/...

> Parts of Rust

Again, you're gonna have to cite what you're talking about because Rust definitely has unit tests: https://github.com/rust-lang/rust/blob/master/library/core/t...

> Parts of Qt. The Vala programming language, Ada GNAT... and many others.

I'm not gonna keep digging up their unit tests, you (hopefully) get the point above.

> I also included this research paper from Microsoft that shows a clear advantage of contracts and code quality

As I said above, nobody is arguing against contracts! A paper showing they're awesome doesn't mean they're substitutes for unit tests in every situation. Your paper only mentions the phrase "unit test" twice, and neither of them is saying DbC substitutes for them.

Re: Algorithms we develop software by

#80

Post by mempko »

dataflow wrote: post #69
mempko wrote: post #65

Earlier quoted context omitted.

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 codebas…

Replying here to your last post here because HN won't let me reply to it (maybe too nested?). You say nobody is arguing against contracts.

> So you'd prefer your contracts to blow up your bugs in your clients' faces, rather than catch bugs yourself prior to releasing the code to them?!

That's you arguing against contracts. Contracts need to blow up when users use the software (including you and your testers before you ship). You should ship if you find no contracts blowing up. But you need to let them blow up in user faces too. They provide valuable information AFTER SHIPPING. Otherwise they lose a lot of their value.

Saying contracts shouldn't run in shipped code misses the whole point about what contracts are.

> That... is literally what unit tests do. Test the software before you give it to users.

No, unit tests test a portion of the software before shipping. My argument is they aren't worth the cost and provide little value. Most of the value comes from SYSTEM tests, integration tests, exploratory testing, fuzz testing, etc. Unit tests are the weakest form of testing.

Here is a great argument against them called Why Most Unit Testing is Waste by Coplien. It's a dense argument which I agree with.

https://wikileaks.org/ciav7p1/cms/files/Why-Most-Unit-Testin...

Post reply on HN