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

101–108 of 108 posts

Re: Algorithms we develop software by

#101

Post by eschneider »

nkozyra wrote: post #7

Write everything (generally, new features) twice has turned out to be really good strategy for me, but it doesn't sit well with bizdev or project managers and tends to be perceived as unnecessary slowness. But if you plow through a feature and get it "working," you'll do much of that work cleaning up the logic and refactoring through your first pass. What rewriting allows you to do is crystalize the logic flow you de…

I spent some time doing consulting with an engineering manager who would keep requesting different (correct) implementations of the same functionality until had seen enough and then he'd pick one. This did lead to some high quality software for what needed to be a high reliability product.

I should probably mention that I was doing consulting engineering here because no employees work work for the guy...

Re: Algorithms we develop software by

#102

Post by HappMacDonald »

AlotOfReading wrote: post #41
mgaunard wrote: post #30

Earlier quoted context omitted.

That's a good point. Particularly good pieces of work are hard to rewrite. I remember rewriting some piece of infrastructure once when I moved to another job, but I failed to summon the energy to rewrite it a second time at another job.

Every time I've pushed through that feeling and rewritten it anyway, the end result was better than the original. The memories eventually come back once I get into the problem and hindsight makes clear how much stuff past-me missed.

Especially in cases where its a project that got derailed or interrupted and I have to start over, the biggest problem for me is inability to concentrate the second time largely from overwhelming and vertiginous deja vu.

Namely, at any given moment my memories of doing the same thing before interfere with my current reality of trying to do it again like intrusive thought microphone feedback.

Re: Algorithms we develop software by

#103

Post by HappMacDonald »

snapcaster wrote: post #97
mgaunard wrote: post #29

Most software has a finite lifetime of a few years. You rewrite everything eventually. What you should be worried about is the code that hasn't been rewritten in ten years.

Weird, i would actually have the opposite conclusion. Can you say more? >What you should be worried about is the code that hasn't been rewritten in ten years. Why would I worry? it's been running for 10 years without significant changes. Isn't that a sign it's more or less accomplishing its purpose?

Well, there's bitrot.

Needs shift. Expectations shift. The foundations that the code relies upon shift.

And familiarity with how things actually work inside of the black box evaporates leaving things distressingly fragile when the foundation finally gives way.

It's like when an old dam has "stood the test of time". More and more people (and business practices) wind up naively circle their wagons around presuming it will remain in operation forever and the consequences of what will happen when it finally does fail add up faster than unchecked credit card debt.

Re: Algorithms we develop software by

#105

Post by mgaunard »

snapcaster wrote: post #97
mgaunard wrote: post #29

Most software has a finite lifetime of a few years. You rewrite everything eventually. What you should be worried about is the code that hasn't been rewritten in ten years.

Weird, i would actually have the opposite conclusion. Can you say more? >What you should be worried about is the code that hasn't been rewritten in ten years. Why would I worry? it's been running for 10 years without significant changes. Isn't that a sign it's more or less accomplishing its purpose?

The people that wrote it probably moved on, so ownership and fit must be weak.

Re: Algorithms we develop software by

#106

Post by dclowd9901 »

rocqua wrote: post #33
dclowd9901 wrote: post #17

Earlier quoted context omitted.

How do you know the contracts are being followed?

Either through assertions, through fuzz testing, or by formal verification.

Maybe I’m confused on the jargon here, but aren’t unit tests assertions?

Re: Algorithms we develop software by

#107

Post by rocqua »

dclowd9901 wrote: post #106
rocqua wrote: post #33

Earlier quoted context omitted.

Either through assertions, through fuzz testing, or by formal verification.

Maybe I’m confused on the jargon here, but aren’t unit tests assertions?

No, a unit test is a stand alone bit of code that sets up the environment, runs a bit of code (the unit under test) and checks if the code worker as expected. This does tend to use assertions.

The idea of using assertions, is to put the assertions inside the 'unit under test' so they are checked every time the code is run (sometimes with a way to disable for performance). Then you can run the code normally, and don't need to write a separate bit of code, that has to set up a proper environment (usually with a lot of 'mock' objects).

This style can probably test less, but still works well for 'design by contract'. You can confirm the caller stuck to any requirements of the input, and you can confirm the code stuck to any post-conditions on it's results.

Re: Algorithms we develop software by

#108

Post by rocqua »

dataflow wrote: post #46
_0ffh wrote: post #43

Earlier quoted context omitted.

Well, that's a mutual misunderstanding then. I meant quite literally neither assertions nor unit tests prevent you from breaking things. Of course they'll help you to catch those mistakes before release. I didn't think that counts as prevention, my bad. Assertions should trigger during system testing if any contracts are broken, so under your interpretation they do prevent breakage as much as units test (meaning befo…

System tests prevent breakage as much as unit tests? Really? How do you "system test", say, string.indexOf(string)? Could you write a system test for this example to show us what you mean and help us see how they're superior to unit tests? And how long and complicated are your system tests to catch breakages "as much as" a unit test would, for this example?

You add an assertion in the indexOf method that checks the substring is indeed present at that index. Then you run your system tests where the indexOf function is called a bunch of times.

The unit tests might be better at testing more edge-cases. But they are a lot of cumbersome work (not in this example, but it is a rather toy example). Unit tests are also less self-documenting than using assertions. They say what the code should do far away from the code itself. An assertion is right there in the code, it says what should be true, and unlike comments, you will be told if they become false.

Post reply on HN