Live data from Hacker News

Algorithms we develop software by

grantslatton.com

11–20 of 108 posts

Re: Algorithms we develop software by

#11
post #8
post #6

"Write everything twice" is a great heuristic. Extreme programming and unit tests is a dumb and wasteful technique. You end up cornering yourself.

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.

Re: Algorithms we develop software by

#12

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

at work? just shoot me then

Re: Algorithms we develop software by

#13
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?

Re: Algorithms we develop software by

#14
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?

Re: Algorithms we develop software by

#15

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

Re: Algorithms we develop software by

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

Re: Algorithms we develop software by

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

How do you know the contracts are being followed?

Re: Algorithms we develop software by

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

Unit tests are only worthwhile when your internal machinery is part of the contract.
Post reply on HN