Live data from Hacker News

Algorithms we develop software by

grantslatton.com

21–30 of 108 posts

Re: Algorithms we develop software by

#21
post #11
post #8

Earlier quoted context omitted.

Sorry, are you saying unit testing is dumb? Not that you'd be the first to say such a thing, but I've never really understood this if people find them valuable. 100% test coverage is one thing, but having some interdependent functions that do one small thing is a perfect use case for unit tests.

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

Re: Algorithms we develop software by

#22
> Write everything twice

There's an enhancement in a software I use/maintain that I wrote once and lost (the PC I wrote kaput and I was writing offline so I also didn't backup). It was an entire weekend of coding that I got very in the zone and happily coded.

After I lost that piece of code I never could get the will to write that code again. Whenever I try to start that specific enhancement I get distracted and can't focus because I also can't remember the approach I took to get that working and get lazy to figure it out again how that was done. It's been two years now.

Re: Algorithms we develop software by

#23
I really like the footnote that indirectly says that sometimes you just need to spin up a background thread to figure something out. Resonates heavily with my experience, to the point where I feel like a lot of the value my experience brings is identifying this class of problems faster. You stumble onto it, recognize it's the think about it passively type and move on to other things in the meanwhile. It would be easy to bang your head on it and get nowhere, sometimes you just need to let it sit for a bit.

Re: Algorithms we develop software by

#24
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…

> it doesn't sit well with bizdev or project managers To be fair, it makes everything twice as expensive. Managers are always going to reflexively push back against that, even if the new feature covers that cost and more.

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

Re: Algorithms we develop software by

#25

> "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.

So glad someone’s here saying it. I am absolutely dreading tomorrow morning now with the thought our manager has also read this article.

I mistakenly read your comment as "dreading tomorrow morning now that our thought-manager has also read this article" which I must have subconsciously decided was inline with the situation.

Re: Algorithms we develop software by

#26
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…

> it doesn't sit well with bizdev or project managers To be fair, it makes everything twice as expensive. Managers are always going to reflexively push back against that, even if the new feature covers that cost and more.

> To be fair, it makes everything twice as expensive.

The article argues it makes it less expensive to reach any specific quality level (above some threshold).

The threshold isn’t really addressed in the article, but it is implied that for any realistic quality need, the write twice approach will be cheaper.

To conclude it makes everything twice as expensive, you have to ignore any cost except the initial write. That’s not realistic.

Re: Algorithms we develop software by

#27
post #11
post #8

Earlier quoted context omitted.

Sorry, are you saying unit testing is dumb? Not that you'd be the first to say such a thing, but I've never really understood this if people find them valuable. 100% test coverage is one thing, but having some interdependent functions that do one small thing is a perfect use case for unit tests.

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.

Confused, how do you ensure that a change to your implementation of some function isn't going to break clients after deployment if you don't have a unit test?

Re: Algorithms we develop software by

#28
post #20

Earlier quoted context omitted.

How do you know the contracts are being followed?

Assertions?

But assertions only tell you you broke someone after the fact (and only if they're enabled)? They don't do anything to help prevent you from breaking them in the first place.

Re: Algorithms we develop software by

#30
post #22

> Write everything twice There's an enhancement in a software I use/maintain that I wrote once and lost (the PC I wrote kaput and I was writing offline so I also didn't backup). It was an entire weekend of coding that I got very in the zone and happily coded. After I lost that piece of code I never could get the will to write that code again. Whenever I try to start that specific enhancement I get distracted and can'…

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.

Post reply on HN