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

51–60 of 108 posts

Re: Algorithms we develop software by

#51

Post by ozim »

lylejantzi3rd wrote: post #16
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…

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

What hits hard is realizing that most features are not worth it. They just shouldn’t be developed.

Unfortunately biznes wants features and more of them and if possible for free.

Re: Algorithms we develop software by

#53

Post by mempko »

dataflow wrote: post #50
mempko wrote: post #49

Earlier quoted context omitted.

The client doesn't run your unit tests, but will run you contracts (because contracts deploy with you software while unit tests dont). You might have realized users of software do things the engineers don't expect, which are not covered in unit tests.

> The client doesn't run your unit tests That's kinda the whole point... you run them to catch bugs and fix them so your clients never see the bugs you caught in the first place. > but will run you contracts (because contracts deploy with you software while unit tests dont). 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?…

You would obviously test the software before it goes to the users. With contracts you would be able to have information from your users that make it MUCH easier to fix. Without contracts you will have a much harder time fixing the bugs. Contracts catch bugs unit tests don't.

Re: Algorithms we develop software by

#54

Post by dataflow »

mempko wrote: post #53
dataflow wrote: post #50

Earlier quoted context omitted.

> The client doesn't run your unit tests That's kinda the whole point... you run them to catch bugs and fix them so your clients never see the bugs you caught in the first place. > but will run you contracts (because contracts deploy with you software while unit tests dont). 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?…

You would obviously test the software before it goes to the users. With contracts you would be able to have information from your users that make it MUCH easier to fix. Without contracts you will have a much harder time fixing the bugs. Contracts catch bugs unit tests don't.

> 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 this whole debate.

Re: Algorithms we develop software by

#55

Post by bdw5204 »

andsoitis wrote: post #13
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…

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 they pop into my head. But once I'm done writing it, I'm done unless I notice an obvious mistake after the fact.

Re: Algorithms we develop software by

#58

Post by actionfromafar »

dclowd9901 wrote: post #14
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…

How would they know? Are they monitoring your code writing?

Depending on how the dev environment is setup, yes. Maybe you need something to go through a CI/CD pipeline. If you can't test it on your local machine, it can easily be visible to many people.

Re: Algorithms we develop software by

#60

Post by mempko »

dataflow wrote: post #54
mempko wrote: post #53

Earlier quoted context omitted.

You would obviously test the software before it goes to the users. With contracts you would be able to have information from your users that make it MUCH easier to fix. Without contracts you will have a much harder time fixing the bugs. Contracts catch bugs unit tests don't.

> 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.
Post reply on HN