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

Cold Showers: For when people get too hyped up about things

github.com

Post reply on HN
Print view View original

111–120 of 243 posts

Re: Cold Showers: For when people get too hyped up about things

#111

Post by Noos »

jedimastert wrote: post #35
ahelwer wrote: post #11

Earlier quoted context omitted.

Yes. Like stoicism. You aren't emotionally insensitive/unintelligent, you're a masculine Roman general!

How is stoicism a SV thing? It's kinda been around for a while...

Stoicism hasn't been popular since Victorian times. I think SV types and rationalists kind of revived it, since it was moral austerity without any real religious background. To an extent they do the same with meditation; it's somehow gone from being something associated with New Age thinking, to something atheist rationalists tout the benefits of while carefully avoiding any hint of spirituality.

Re: Cold Showers: For when people get too hyped up about things

#112

Post by aidenn0 »

Taikonerd wrote: post #58

I read this and thought, "oh, the author is calling out formal verification as overhyped? Hillel Wayne ( https://hillelwayne.com/ ) is going to be angry! Wait, who wrote this..."

Overhyped is not the same thing as bad. I program in common lisp, it is by far my favorite environment for developing. I also think just about every blog post and reddit comment by someone who has just discovered lisp greatly overstates its advantages.

Re: Cold Showers: For when people get too hyped up about things

#113

Post by mumblemumble »

bob1029 wrote: post #71
hans_castorp wrote: post #45

Earlier quoted context omitted.

> If at this point you are still finding that SQLite is not as fast or faster than SQL Server, MySQL, et.al., then I would be very surprised. What about large aggregation queries, that are parallelized by modern DBMS? Does it still scale that well if you have many concurrent read and write transactions (e.g. on the same table)?

We aren't running any reports on our databases like this. I would argue it is a bad practice in general to mix OLTP and OLAP workloads on a single database instance, regardless of the specific technology involved. If we wanted to run an aggregate that could potentially impact live transactions, we would just copy the SQLite db to another server and perform the analysis there. We have some telemetry services which ope…

> I am not aware of any hosted SQL technology which is capable of magically interleaving large aggregate queries with live transactions and not having one or both impacted in some way. At the end of the day, you still have to go to disk on writes, and this must be serialized against reads for basic consistency reasons.

I do sometimes wonder if dirty reads are what the business folks actually want.

Not necessarily unconstrained dirty reads. But if it were possible to say, "The statistics in your reports may only be accurate to (say) +/- x%," would that be good enough?

Going really philosophical, might they even make better decisions if they had less precision to work with? There are certainly plenty of studies that suggest that that's basically how it works when people are managing their investments.

Re: Cold Showers: For when people get too hyped up about things

#114

Post by mumblemumble »

zimpenfish wrote: post #92
SNACKeR99 wrote: post #87

Earlier quoted context omitted.

This is a great answer. The details REALLY matter. One of my best early tech success stories was rewriting a SQL query that took 27 hours to one that took ~5 seconds. This was running on a very large Oracle cluster. They had poured more and more money into hardware and licensing trying solve this. In the end, it was a matter of turning a cursor-based query into a set-based query.

In some respects, I think the constraints of something like SQLite can focus people's attention on making things work properly rather than throwing hardware at the problem. I can think of a couple of places I've worked where they had simple problems that could have been solved by some thinking and coding but instead were solved* by more expensive hardware.

The last time I reduced database server load by 70% by just spending a week tuning indexing strategies and ill-performing queries, nobody thanked me. Sure, a new database server costs way more than a week of my time, but that is completely beside the point.

The point is that I robbed someone of the chance to buy a shiny new computer.

Re: Cold Showers: For when people get too hyped up about things

#115

Post by theptip »

> Agile Methods: The Good, the Hype and the Ugly (Video) (https://www.youtube.com/watch?v=ffkIQrq-m34)

Thoughts on this one? I found the presentation to be somewhat mixed.

I found the initial comb through of the agile principles to be needlessly pedantic ("'Simplicity... is essential' isn't a principle, it's an assertion!"); anyone reading in good faith can extract the principle that's intended in each bullet of that manifesto.

The critique of user stories (~35 mins in) was more interesting; it's something we've been bumping up against recently. I think the agile response would be "if your features interact, you need a user story covering the interaction", i.e. you need to write user stories for the cross-product of your features, if they are not orthogonal.

I'm not really convinced that this is a fatal blow for user stories, and indeed in the telephony example it is pretty easy to see that you need a clarifying user story to say how the call group and DND features interact. But it does suggest that other approaches for specifying complex interactions might be better.

Maybe it would be simpler to show a chart of the relative priorities or abstract interactions? E.g. thinking about Slack's notorious "Should we send a notification" flowchart (https://slack.engineering/reducing-slacks-memory-footprint-4...), I think it's impossible (or at least unreasonably verbose) to describe this using solely user stories. I do wonder if that means it's impossible for users to understand how this set of features interact though?

Regarding the purported opposition in agile to creating artifacts like design docs, it's possible that I'm missing some conversation/context from the development of Agile, but I've never heard agile folks like Fowler, Martin, etc. argue against doing technical design; they just argue against doing too much of it too early (i.e. against waterfall design docs and for lean-manufacturing style just-in-time design) and that battle seems to have largely been won, considering what the standard best-practices were at the time the Agile manifesto was written vs. now.

Re: Cold Showers: For when people get too hyped up about things

#116

Post by theptip »

j1elo wrote: post #88

I'm already thrilled waiting for an addition with "Kubernetes everywhere" ice shower.

This is probably a good place to start: https://github.com/hjacobs/kubernetes-failure-stories

(Not a balanced evaluation, just cherry-picking failures. But I suppose we're at the point in the hype cycle where it's easier to find success stories being talked about.)

Re: Cold Showers: For when people get too hyped up about things

#117

Post by andikleen3 »

I can confirm the issues with formal methods.

I was working on a new type of locking mechanism and thought I would be smart by modelling it in spin [http://spinroot.com], which has been used for these kind of things before.

I ended up with a model that was proven in spin, but still failed in real code.

Given that's anecdata with a sample size of 1, but still was a valuable experience to me.

Re: Cold Showers: For when people get too hyped up about things

#118

Post by dynamite-ready »

fmakunbound wrote: post #61
rwoerz wrote: post #28

We software engineers are still more like alchimists rather than chemists. That list reminds me of [1], which rants about this state of affairs and [2] that puts many beliefs to the test. [1] https://youtu.be/WELBnE33dpY [2] https://www.oreilly.com/library/view/making-software/9780596...

In addition to that, I also feel calling ourselves engineers is a stretch.

I think that's a very interesting point.

I think software 'engineering' is uniquely ambiguous in this regard, because software development as a discipline is in equal parts both design, and construction, and the design part bleeds into the 'construction' part, corrupting it (for want of a better word) in a way you would imagine that 'pure' engineering would not.

Re: Cold Showers: For when people get too hyped up about things

#119

Post by mistermann »

ravenstine wrote: post #39

I think the best takeaway from this is that the software industry makes lots of claims about development processes, but so little actual research is done in trying to validate those processes. It's all mostly based on opinion.

I reckon the same general phenomenon extends to most any human endeavor on the planet at the macro and micro level (and everything in between), and hardly anyone even notices they are doing it unless someone happens to point it out, which typically (in my experiences) then results in some form of rationalization. It's like (or actually is) humanity is living in a fantasy world at all times, but we're unable to realize it, or even consider it.

Re: Cold Showers: For when people get too hyped up about things

#120

Post by wtetzner »

GlennS wrote: post #48
pantaloony wrote: post #30

Earlier quoted context omitted.

I don’t get the cost claims. The time it takes to note which type I intend something to be is mostly either so low that I recover it via improved hints and such very quickly, or larger but only because I’m documenting something complex enough that I should have documented it anyway, whether or not I was using static types, because it’ll be hell for other people or future-me to figure out otherwise. It seems like a la…

I would like to be able to explain the cost part better. It may just be personal bias of course. 1. There's no guarantee the correct theoretical model of your program fits the type system of your programming language. 2. Sometimes there are multiple correct models for different purposes in the same program, similar to how sometimes you need multiple views onto the same database tables. 3. Sometimes you just need the…

> 2. Sometimes there are multiple correct models for different purposes in the same program, similar to how sometimes you need multiple views onto the same database tables.

Just wanted to point out that even though you can have multiple views or your database tables, they all still adhere to the same type system.

Post reply on HN