[HN Gopher] Algorithms we develop software by
___________________________________________________________________
Algorithms we develop software by
Author : xal
Score : 137 points
Date : 2024-08-18 18:47 UTC (4 hours ago)
(HTM) web link (grantslatton.com)
(TXT) w3m dump (grantslatton.com)
| from-nibly wrote:
| > "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.
| colechristensen wrote:
| "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.
| zug_zug wrote:
| Yeah, I've certainly seen cases where something was overbuilt
| and 90% of the time was wasted.
|
| But I've also worked at places where things were underbuilt
| (e.g 0 test environments whatsoever except prod). If there
| was a gun to my head, to finish something in 1 hour, I'd test
| in prod.
|
| So I think advice that sometimes is useful, sometimes is
| damaging, isn't really helpful. Not unless there's an easy
| way to tell which situation is which.
| aidos wrote:
| > In practice, none of the day-long plans are actually a day.
| The gun isn't actually to your head. You can go home and sleep.
| Lws803 wrote:
| 100% this should never be an excuse to push for a faster
| outcome. I have to admit though, as a personal mental exercise,
| this has saved me countless of hours from going down the rabbit
| hole of over-engineering. Some problems just need a simple
| solution, sometimes even without any changes to code.
| haliskerbas wrote:
| at work? just shoot me then
| dclowd9901 wrote:
| So glad someone's here saying it. I am absolutely dreading
| tomorrow morning now with the thought our manager has also read
| this article.
| athrowaway3z wrote:
| 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.
| hn_go_brrrrr wrote:
| Sounds like you need a different manager.
| mempko wrote:
| "Write everything twice" is a great heuristic. Extreme
| programming and unit tests is a dumb and wasteful technique. You
| end up cornering yourself.
| nkozyra wrote:
| 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.
| mempko wrote:
| 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.
| dclowd9901 wrote:
| How do you know the contracts are being followed?
| _0ffh wrote:
| Assertions?
| dataflow wrote:
| 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.
| _0ffh wrote:
| Of course they don't, how could they? How could anything,
| for that matter? (Apart from guarantees you could ensure
| statically, natch.)
| dataflow wrote:
| > Of course they don't, how could they? How could
| anything, for that matter?
|
| Uh, that's literally what unit tests do? They tell you if
| you broke any of the cases they test for, before you
| release your implementation to other people...
| _0ffh wrote:
| 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 before shipping).
| dataflow wrote:
| 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?
| rocqua wrote:
| Assertions triggering in integration tests are different
| from unit tests. They don't involve writing mocks. They
| are generally closer to the code, especially with design
| by contract, so they are more likely to be fixed during a
| refactor. They encode what you believe your code should
| do more directly. And they can be used as a basis for
| formal verification.
| _0ffh wrote:
| Hey, I'm arguing in favour of contracts and assertions
| here... XD
|
| I even considered formal verification, if under another
| name.
|
| Ed.
|
| I think I hit a posting limit. After reading dataflow's
| answer to gp I think I interpreted ggp differently from
| both of you.
|
| 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_.
| rocqua wrote:
| Tests have the same effect right?
| rocqua wrote:
| Either through assertions, through fuzz testing, or by
| formal verification.
| sitkack wrote:
| Unit tests are only worthwhile when your internal machinery
| is part of the contract.
| jackcviers3 wrote:
| 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
| dataflow wrote:
| 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?
| mempko wrote:
| 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.
| dataflow wrote:
| > 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?!
| mempko wrote:
| 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.
| dataflow wrote:
| > 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.
| mempko wrote:
| 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.
| gavmor wrote:
| "Write everything twice" is sometimes called a "spike."[0]
|
| > A spike is a product development method originating from
| _extreme programming_ that uses the simplest possible program
| to explore potential solutions.
|
| In my career, I have often _spiked_ a solution, thrown it away,
| and then written a test to drive out a worthy implementation.
|
| 0. https://en.wikipedia.org/wiki/Spike_(software_development)
| nkozyra wrote:
| 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 developed the first time and start cherry-
| picking in a more linear fashion to meet the blueprint. It also
| tends to reduce the urge (/ need) for larger scale refactorings
| later on.
| andsoitis wrote:
| 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?
| stanac wrote:
| Worst kind of jira ticket is just a link to a document that
| can be edited anytime. In that case I just replace the link
| with a new link pointing to the fixed version of the document
| and inform the author of the ticket/document about it.
| bdw5204 wrote:
| 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.
| dclowd9901 wrote:
| How would they know? Are they monitoring your code writing?
| actionfromafar wrote:
| 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.
| lylejantzi3rd wrote:
| > 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.
| edflsafoiewq wrote:
| The second time doesn't cost as much as the first.
| jrvarela56 wrote:
| And the first is cheaper than a 'regular single version' bc
| you build it with the thought that you will throw it away.
| richk449 wrote:
| > 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.
| ozim wrote:
| 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.
| jesse__ wrote:
| This is one of the best "programming advice" posts I've ever
| read, right up there with the grug brained developer.
| 201984 wrote:
| Not sure why this was downvoted?
| jesse__ wrote:
| Surprised me too..
| gamegoblin wrote:
| I appreciated the comment (author here)
| BoiledCabbage wrote:
| Likely most people don't know what you're referring to and
| assumed you thought the advice was bad.
| a1o wrote:
| > 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.
| mgaunard wrote:
| 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.
| AlotOfReading wrote:
| 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.
| Etheryte wrote:
| 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.
| mgaunard wrote:
| 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.
| justinl33 wrote:
| > start over each day This reminds me of "spaced repetition" in
| learning theory. Drilling the same problem from scratch is a
| great way to get better at iterating through your rolodex of
| mental models, but so many people prioritize breadth because they
| think it is the only way to generalize to new problems.
| rmnclmnt wrote:
| > Write everything twice
|
| I'd say << Write everything three times >> because it usually
| take 3 versions to get it right: first is under-engineered,
| second is over-engineered and third is hopefully just-right-
| engineering
| steve918 wrote:
| I like the "gun to the head" heuristic but I would probably
| rephrase it to be something like "If you only had 24hrs to solve
| this or the world would come to an end".
| hintymad wrote:
| I remember seeing somewhere a popular list of top 10 algorithms
| used in systems, and it's kinda depressing to realize that the
| most recent algorithm on the list, Skip List, was invented
| roughly 30 years ago, and every single one of them was taught in
| an introductory data structure course. That is, we most likely do
| not need to study the internals of algorithms nor need to
| implement them in production. For such a long time in history,
| smart and selfless engineers already encapsulated the algorithms
| into well abstracted and highly optimized libraries and
| frameworks.
|
| Of course, there are exceptions. ClickHouse implemented dozens of
| variations of HashTable just to squeeze out as much performance
| as possible. The algorithms used in ClickHouse came from many
| recent papers that are heavy and deep on math, which few people
| could even understand. That said, that's just exception instead
| of norm.
|
| Don't get me wrong. Having a stable list of algorithms is
| arguably a hallmark of modern civilization and everyone benefits
| from it. It's just that I started studying CS in the early 2000s,
| and at that time we still studied Knuth because knowing
| algorithms in-depth was still a core advantage to ordinary
| programmers like me.
| layer8 wrote:
| This reminds me of https://ntietz.com/blog/throw-away-your-first-
| draft/, previously discussed in
| https://news.ycombinator.com/item?id=37003910.
___________________________________________________________________
(page generated 2024-08-18 23:00 UTC)