Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shipping Culture Is Hurting Us

bitbashing.io

Post reply on HN
Print view View original

31–40 of 169 posts

Re: Shipping Culture Is Hurting Us

#31

Post by 23david »

digi_owl wrote: post #27
saidajigumi wrote: post #20

Earlier quoted context omitted.

Maybe that depends on who's uttering the phrase and what it means to them. Some points in the space: - "Devops" as a movement encompassing the ideas that developers should not be walled off from operational realities, and that software operations tasks should be encoded as repeatable, testable software (vs ad-hoc stuff a sysadmin does on a box somewhere). - "Devops" as "oh look, we can hire less people and just get s…

The way i have seen it used was more like the inverse of your first example, where one go from encoded and tested sysadmin tasks to "lets throw into production any newfangled thing the devs (monkeys hammering keyboards, more like it) wants to use".

Devops can definitely be used as a very expensive bandaid around poor engineering practices.

But there's more to it... sometimes the engineering work it takes to prevent something from crashing is much less than just monitoring and restarting when failures are detected. Maybe "failure engineering" is a good term for a lot of the value Devops techniques can bring to a team?

Re: Shipping Culture Is Hurting Us

#32

Post by dbaupp »

pwnna wrote: post #29
kazinator wrote: post #21

Earlier quoted context omitted.

The stupid thing about IEEE NaN is that it's not equal to itself! If variable x holds a NaN, then (x == x) is false. This violates: http://en.wikipedia.org/wiki/Law_of_identity If (x == x) tests false, then it asserts that x is not itself, which is logically preposterous. ANSI Common Lisp has a bit of this problem in it too, but it's not required ; it is there for some weird historic implementations. That is to say,…

Don't quote me on this, but I recall the rational for NaN is because NaN is typically the result of a division by 0. Divisions by 0 can be thought of as infinity (for the sake of this explanation, but mathematicians will cringe), but it is not any particular infinity. In the sense that x / 0 does not necessarily have to equal y / 0. For that definition, the result of a division by 0, NaN, must not equal itself. You c…

IEEE division by zero gives positive (or negative) infinity (with the sign determined by the sign of the zero). NaN crops up with e.g. sqrt(-1) and infinity - infinity for which there is no way to define a sane answer.

Re: Shipping Culture Is Hurting Us

#33

Post by ChuckMcM »

spitfire wrote: post #6
ChuckMcM wrote: post #5

The problem that I have with this thesis (that shipping culture is hurting us) is the results people have. You can certainly argue that a better result could be achieved by taking more care with your design, but it is unclear that in doing so you would have achieved something more "valuable" than you did by shipping and iterating. I do agree with Gary Bernhardt that infrastructure is not getting the attention it dese…

The thing is the "Think carefully and create deliberately" approach has been tried so very few times. But when we have tried it we've gotten Lisp machines, ACID RDBMs, strong typing, and many other important and very useful tools. I'd say it's worth a shot more often. We know we're in a world of hurt now, but the argument against it is "oww. Devil we don't know!". Math is hard, lets go shopping.

"We" and by that I mean software engineers, used to do the 'Think carefully and create deliberately' all the time, we called it software architecture. But "They", and by they I mean software engineers with a 'ship it' culture, got stuff to market faster and improved it faster, and called it 'ship and iterate'.

Lots of people were called out as "old fogeys" or "dinosaurs" when they asked to think through some of the ramifications of shipping things. Those folks got trained that such behavior is a quick way to get managed out of an organization.

It would be interesting if, as an industry, wave 3 (which like wave 2 before it is a decimal order more engineers than its preceding wave) decided to go back to a more mindful way of developing software. And if so they could remain employed amongst the wave 4 cohort.

Re: Shipping Culture Is Hurting Us

#34

Post by mbrubeck »

DiThi wrote: post #8

> Instead we get some bizarro-world where where the type of NaN (“Not a Number”) is number, where NaN !== NaN*, and a chart like this exists for something as simple as comparing two values. That's the definition of NaN in virtually any programming language with floating point numbers. And the comparison table makes sense with the rule "when types are incompatible, both are casted to strings". Just use === instead of…

Yes. The research culture that produced Haskell, for example, is far from the "shipping culture" that produced JavaScript 1.0, and yet:

    > let x = 0/0
    > x
    NaN
    > x == x
    False
    > :type x
    x :: Double
(and yes, Double is an instance of the Num type class)

The author programs in C++ and D. I wonder if he knows the value of (NaN == NaN) in those languages?

Re: Shipping Culture Is Hurting Us

#35

Post by mxfh »

andrewstuart2 wrote: post #14
DiThi wrote: post #8

> Instead we get some bizarro-world where where the type of NaN (“Not a Number”) is number, where NaN !== NaN*, and a chart like this exists for something as simple as comparing two values. That's the definition of NaN in virtually any programming language with floating point numbers. And the comparison table makes sense with the rule "when types are incompatible, both are casted to strings". Just use === instead of…

Also in logic. Not something is never equal to not the same thing. A bird is not a rock. A computer is also not a rock. Clearly not equal to each other.

I think people confuse the nature of NaN with the result of isNaN() a lot, this being the source of this confusion.

Re: Shipping Culture Is Hurting Us

#36

Post by kazinator »

pwnna wrote: post #29
kazinator wrote: post #21

Earlier quoted context omitted.

The stupid thing about IEEE NaN is that it's not equal to itself! If variable x holds a NaN, then (x == x) is false. This violates: http://en.wikipedia.org/wiki/Law_of_identity If (x == x) tests false, then it asserts that x is not itself, which is logically preposterous. ANSI Common Lisp has a bit of this problem in it too, but it's not required ; it is there for some weird historic implementations. That is to say,…

Don't quote me on this, but I recall the rational for NaN is because NaN is typically the result of a division by 0. Divisions by 0 can be thought of as infinity (for the sake of this explanation, but mathematicians will cringe), but it is not any particular infinity. In the sense that x / 0 does not necessarily have to equal y / 0. For that definition, the result of a division by 0, NaN, must not equal itself. You c…

I understand the point perfectly. However, if I have a NaN which is captured in a lexical variable (perhaps the result of a division by zero, as you note) then in fact I do have a particular infinity: whatever object is inside that darned variable! If I do another division by zero, then sure, hit me with a different NaN which doesn't compare equal to the first one I got. But don't make my variable not equal to itself.

Re: Shipping Culture Is Hurting Us

#37

Post by dkarapetyan »

digi_owl wrote: post #12
didgeoridoo wrote: post #2

The author talks about languages and technologies (JS, Mongo), but he's really getting at something deeper. The real danger of the "ship it" culture is that things that can't be "shipped" right away — things that require solving really hard problems — tend to fall off our collective radar because there is just SO MUCH cool and (relatively) easy stuff to do right now. PG has a great term for this: "schlep blindness":…

Makes me wonder if this is why i find the whole "devops" concept to be raising my hackles.

How about "full-stack developer"?

Re: Shipping Culture Is Hurting Us

#38

Post by soup10 »

saidajigumi wrote: post #24

This whole article makes me want to scream, if only because the author seems to have never heard of the concept of Path Dependence[1]. I could utter a similar rant, on how terrible it is that we're stuck with awful legacy dumb AC lightbulb sockets everywhere, and wouldn't it be nice if the entropy fairy just waved a magic wand and we all had 'net-connected DC smart sockets for our wonderful Future Bulbs. But that kin…

Javascript has become the defacto browser programming language, even though it's objectively awful for complex software. The only reason it's achieved it's high status is because browser developers refused to cooperate and develop something better. Microsoft and Apple view software lockin as a competitive advantage and have actively undermined technologies they thought were threatening(java and flash amongst others). The explosion of Html5 and javascript was more of a 'nature will find a way' type development and can almost entirely be credited to Google and various web companies pushing it and making it better.

It's still a very flawed technology stack for complex web-apps though and it's very reasonable to suggest that we could do a lot better.

Re: Shipping Culture Is Hurting Us

#39

Post by dkarapetyan »

23david wrote: post #31
digi_owl wrote: post #27

Earlier quoted context omitted.

The way i have seen it used was more like the inverse of your first example, where one go from encoded and tested sysadmin tasks to "lets throw into production any newfangled thing the devs (monkeys hammering keyboards, more like it) wants to use".

Devops can definitely be used as a very expensive bandaid around poor engineering practices. But there's more to it... sometimes the engineering work it takes to prevent something from crashing is much less than just monitoring and restarting when failures are detected. Maybe "failure engineering" is a good term for a lot of the value Devops techniques can bring to a team?

But isn't that what all systems engineering is all about? Feedback loops with resiliency. Why is it that the software folks think they have discovered something new?

Re: Shipping Culture Is Hurting Us

#40

Post by cwyers »

kazinator wrote: post #21
DiThi wrote: post #8

> Instead we get some bizarro-world where where the type of NaN (“Not a Number”) is number, where NaN !== NaN*, and a chart like this exists for something as simple as comparing two values. That's the definition of NaN in virtually any programming language with floating point numbers. And the comparison table makes sense with the rule "when types are incompatible, both are casted to strings". Just use === instead of…

The stupid thing about IEEE NaN is that it's not equal to itself! If variable x holds a NaN, then (x == x) is false. This violates: http://en.wikipedia.org/wiki/Law_of_identity If (x == x) tests false, then it asserts that x is not itself, which is logically preposterous. ANSI Common Lisp has a bit of this problem in it too, but it's not required ; it is there for some weird historic implementations. That is to say,…

NaN literally means "not a number." Lots of things aren't numbers. The letter a is not a number. The square root of negative 1 is not a number (at least, not one representable in floating point math). a is not equal to the square root of negative 1.
Post reply on HN