6 ms·
This is a good lesson. I've done a lot of pilot studies, prototypes, proof-of-concept experiments. It is scary^1 how many times "let's just get this tested and
by checkyoursudo 3y ago
This is a good lesson. I've done a lot of pilot studies, prototypes, proof-of-concept experiments. It is scary^1 how many times "let's just get this tested and see if it even works" turns into "welp, that worked and we don't have time or funding to do another one, so that's the final version." The constraint is often time. Gotta get a product out, or run an follow-on experiment that depended on the first, or submit a paper or funding application, or whatever.
Test the thing you want to test!
1. Not scary like fear, just like, I don't know, astonishing.
- Dalewyn 3y agoAn old Russian proverb goes: There is nothing more permanent than a temporary solution.
- contingencies 3y agoNice. Added to https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup
- pmarreck 3y agooooh, it's on nix! done and done
- justinclift 3y agoYeah, I've heard the same thing in several contexts before too. Without any mention of nationality. :)
- toyg 3y agoIn Italy we have "temporarily permanent" laws. I wish I were kidding.
- _the_inflator 3y agoIn hindsight. ;) To me this sounds like the winner's bias: in hindsight. It is hard to balance a prototype against a "works under all conditions no matter what they are" production-ready solution without growing into a hard to handle monster solution. On the other side I know off quite some overhyped apps, that rest on a overpowered machine, because the specs did not account for one thing: no one cares about the product. Extensibility is the key to balance certain weaknesses in a spec.
- rinka_singh 3y ago:-P ChatGPT?
- chrisfosterelli 3y agoOn the flip side, how many times do we hear about projects that failed because the dev team was stuck building things that were never needed or never used? It's hard to see the future.
- ajross 3y agoThat's it. The causality analysis in the grandparent is exactly backwards. We don't live in a world of "productized prototypes" because people are too lazy to do things right. We live in the world of prototypes because prototypes are the only products that reach market. Even where beautiful works of engineering exist, then tend to be beaten to the punch by the competing prototype anyway. You don't treat this by whining that the prototypes are winning. You treat it by finding ways to cleanly evolve prototypes[1], and by collecting intuition (c.f. the linked article) about common mistakes and how to avoid them. [1] Once upon a time in an age lost to history, this was the idea behind something called "agile". The thing we call "agile" today is pretty much the opposite.
- pmarreck 3y agoRight. In that vein, it wasn't the 32 bit limitation that was the real problem. It was the inescapable 32 bit limitation built into the design that was the problem. They could have spent a few bits to version the packet format, for example, which would have at least provided an escape hatch. Or heck, a single bit: Value of 0, known original format. Value of 1, unknown format (or known future format, to be parsed by some future IP packet decoder, but which errors out old decoders). And they repeated the same mistake with the IPv6 design by not making it an evolution of or backwards-compatible with IPv4. Literally neither of these was built with scalability in mind.
- gizmo686 3y agoThe first 4 bits of both IPv4 and IPv6 packets are a version field.
- 3y ago
- saghm 3y agoIf by doing things the way I need them to work now rather than the future lets me achieve the success, longevity, and ubiquity of TCP, I think I'm, fine with waiting until later to figure out things that don't matter right away.