Worst Software Metrics - <AUTHOR> https://www.gitclear.com/blog/the_4_worst_software_metrics_agitating_developers_in_2019 <comment><USER2> At a previous job of mine, they implemented a "personal improvement plan" for employees who were below management's "desired productivity". There was no warning, no heads up that they would be measuring our GitHub accounts, and it had absolutely no context of what each person had been working on. These reviews came after a 360 peer review, and absolutely blindsided the team. Several of my coworkers left early for the day and didn't come in for the rest of the week. I got calls all day from various people asking what happened in my 1:1, what was said, etc...

I wish I could show management how negatively and immediately that move affected the culture & mood of engineering at that company. It was an overnight change, and going forward it basically killed all trust in management. I stayed around for a little bit longer, but I should have quit the second they started those measurements.

It absolutely murdered the confidence of our junior devs. Of the senior engineers who were put on it, none of them really had any idea what they were doing wrong or how to improve, as no feedback was given about any of that, just that they weren't enough. Some of our seniors had 15+ years of experience in software and were industry experts, but it didn't matter: They hadn't been hitting the number of commits and pull requests and tickets per week that management insisted on.

When management was confronted about it, they admitted that code metrics aren't a good measurement of productivity, but then insisted that they "needed something".

It turns out, they only used code metrics as a bludgeon to get rid of the employees they wanted gone, and since then that's all I've been able to see code metrics as. They're a battering weapon used to give HR a performance reason to justify firing you.

<comment><USER3> I'm sorry this experience left you scared of metrics but it doesn't mean they are bad, just that people need to know how to use them.

I've had this exact conversation before and the extremism of "metrics are always weapons" was a contributing factor for me to leave a, say, less metrics-inclined workplace. Just saying there has to be balance.

<comment><USER4> I've been a professional software developer for twelve years, and while I'm trying to keep an open mind, I have yet to see any useful metrics for what we do. Like, useful AT ALL. I can think of zero numerical metrics that can accurately tell you what's going on with a team. Number of commits, burndown charts, velocity, issues closed/created, whatever, they're all simultaneously easily game-able and also create bad incentives.

And by the way this isn't sour grapes, metrics have almost always made me look good. One job I left, I had so many more commits than the next person that it took them two years _after I left_ to catch up to me. And yet I'm absolutely _certain_ I was not the most useful person on that team. The most useful person was the guy that was writing the extremely sophisticated modelling kernel, and if you only looked at the metrics he probably looked borderline useless, but in actual terms he was by far the most valuable and important person on our team.

What scares programmers is, everyone on our team knew that, and any sort of manager with programming experience probably knows that, but you know that those stats are going to eventually float up to someone who _doesn 't_ know that the numbers are bogus. (After all, they wouldn't be tracking these numbers if they knew how bad they are). So decisions _do_ get made from these numbers, even when people promise they wont.

<comment> Fire-Dragon-DoL I'm completely with you on that. As for an example where some metrics might be useful: some form of complexity measurement of the code helps a new developer on the team discover where to poke to find out issues, as well as which parts are critical. While far from perfect, it gives you a starting point that's possibly better than "randomly open files in project".

Now, this comes with interesting points: \- the metrics in this case are in the hands of the professional in the field \- the metrics are there to serve the person itself, without affecting others

Metrics on commits, line of code, tickets closed are useless from my point of view. If you ask in a developer team who is weak at the moment (assuming there is no room for improvement is stupid) gives better results. A decent programmer is able to spot fake ones and is able to notice performance difference over time (not perfectly, but definitely better than metrics).

Not to mention, I would be surprised if none of the team would start complaining if someone is doing no work and still getting salary.

You can spend an entire day teaching your team something important about the project you are working on, have no commits about it. Or you can use half the day walking around thinking how to solve a bug. Not a single line is written, but that's how some problems are solved.

I started counting in my working hours even when sometimes I wake up in the middle of the night and my mind solves programming problems for 1 hour (let's say). I have a decent employee, being at my desk typing is not what I'm paid for, I'm paid for solving problems with software engineering to the best of my knowledge.

</comment></comment></comment></comment><comment><USER4> Ugh the "velocity" one really hits home. A couple of jobs ago one of our project managers was constantly showing burn down charts (which, of course, never burned down); along with our "velocity". The funny thing is, because we were doing t-shirt-size/fibonacci, our velocity numbers varied so wildly that it was essentially a random number generator. Then we were required fit all our stories within a "budget" of our "average" velocity.. What are you supposed to do with the average of a random number between 0 and 200? Apparently a lot, because these insane numbers that had no actual tie to reality were used to determine how much we were allowed to "commit" to. Never mind that some months we'd finish 50 story points and some months 250 (because, again, the numbers were a fiction); we were always trying to fit things into 90 story points.

Luckily all this useless theater only took up an entire day every two weeks. If you assume everyone on the team was making about $50 an hour, and it was about 6-8 people in attendance to these things, then it came out that this very dumb "estimation" process took 6 people * $50/hr * 6 hours... so about 1800 dollars. (Not including the project managers salary, which given that he drove around a very fancy luxury car, was probably a lot more than the rest of us).

And people wonder why I don't take scrum seriously.

<comment><USER5> To be fair, that's very poorly implemented. You should have reference stories for what is a 1 in complexity and the highest value should be low, like 13, which forces you to break things down and forces the PM to write better specs.

<comment><USER4> We did all of these things. But we had this ridiculous Fibonacci thing where you would end up with a conversation like this:

dev: well, this looks like it's somewhere between a 5 and an 8, so let's call it 6.

pm: no 6 is not allowed, it must be either a 5 or an 8.

dev: ok, lets call it an 8.

Ok so that's a very plausible conversation, right? I'm sure we've all had it. But just that rule alone made the estimate on this story 20% off, just to satisfy a rule. I'm perfectly fine with that, if we're only talking about that one story. If we're both happy that this might go 20% faster or 20% slower than predicted, no big deal. But if you're going to include it in a larger rollup, you've included a very large error term with your number that you need to carry along with the rest of the calculations. Did you ever take a physics course in college? (A real one -- not one of the baby ones they gave to business and liberal art majors). If they were good, they probably made you deal with carrying an error term in your math. You probably even hated it because it was a pain in the ass to deal with, but it's also kind of important. If you're adding together 50 numbers that are all off by 20%-50% and chucking away the error term, your summary and conclusion are _absolute garbage_ if you do not properly keep the error term included. Math is unforgiving like that. Presenting that absolute garbage as "data" is, in my opinion, professional incompetence. It just is. I guess the softening factor is that so many people do it that it's not an individual incompetence, it's a lack of competence in the profession itself essentially.

<comment><USER5> Well yeah, you don't have to use fib numbers. Not really sure why that's popular anyway.

Personally I prefer being on a small team with excellent devs that don't require this kind of stuff. I built products that made many millions of dollars a year with just me, a PM, and one other dev with none of this stuff.

</comment></comment></comment></comment><comment><USER6> Does anybody know of a study documenting that measuring and reporting software code quality metrics actually improve the project/product team's ability to deliver?

So far I've only found studies documenting that measuring code quality improve the team's ability to improve the measurement figures. That doesn't count. More or less any measurement will be gamed if anyone think they are used for something. But has anybody measured if these measurements actually are helpfull?

<comment><AUTHOR> This is a terrific question, and a topic I've thought about quite a bit while we've built our product (context: as the OP, I've toiled on "how to prove metrics are signal-bearing" for a couple years now).

The problem we always end up at is "what measurable output can we rely upon to tell the story that a project's fortunes are improving"? To date, its been challenging to find a compelling answer. This may be why I'm unaware of any study that addresses the question.

One possible workaround would be to take experts in the field, and try to translate their qualitative interpretation into input that drives a metric. e.g., if Andrew Clark from React could list three directories that harbor disproportionate tech debt in their project, we could calibrate our Open Repo Directory Browser to identify the factors that were unique to that directory. This could then help managers pick out when and where its appropriate to make payments to reduce their tech debt.

Unfortunately, the prominent open source developers aren't answering my emails at this point. And even if they did, it's still a long road to translate qualitative expert opinion into provable long-term benefits. But I think the environment for making that leap is as ripe as ever. We just need to keep working toward figuring out the most desirable+measurable outputs.

<comment><USER7> This sounds like something Felix von Leitner might be interested in. Consider collaborating.

[https://blog.fefe.de](https://blog.fefe.de)

</comment></comment></comment><comment><USER8> I have a solution to these metric gotchas. Don't install Jira at all and then you won't be tempted by any of them. Better yet, don't hire a manager at all. Instead get one or two senior devs and include them in some business discussions and incentives.

<comment><USER4> _gasp_ include senior devs in a conversation about development? Blasphemy. At so many places it's like there's some unwritten law that you can't include developers in any sort of business conversation, you need to hire a project manager as a go-between in order to badly translate things between business and development so neither side actually knows what's going on.

<comment><USER9> Why is this so true. I usually assume that when a large percentage of people do something that seems dumb, it's usually because there is some reason I don't understand and not because they all coincidentally decided to be idiots in the same way. Occasionally there is a common pitfall that does cause them all to be dumb in the same way, and more often there's a good reason. In this case though, it's so common but I can't see how there could possibly be a reason for this. Maybe tech companies just tend to have really small meeting rooms with only a few chairs in them.

<comment><USER4> I think the problem is this: if you talk to any good software developer (or scientist for that matter), they're always going to speak in probabilities and hedge everything. And they're absolutely correct to do this, because it's the reality.

The problem is, the business people (generally) have _no interest_ in this. They're interested in certainties. They aren't being irrational either -- they need to go out and sell, raise money, etc., and to do that they need to be able to say "we're shipping on december 5th" and "absolutely we can do that for you". Having the developers say "well, uh, maybe we can do that in three months but we don't really know" makes their lives 10x harder even if it's true.

So this is where project managers come into the picture. They don't promise the most _efficient_ use of human resources. What they offer is a _predictable_ use of human resources. In reality this drags everyone down into a very gloomy mediocrity and leads to ineffectual organizations. But to the business person, it seems great because they gain the illusion of control.

In that light, our current predicament makes perfect sense: project managers are the shamanic priests doing a rain dance, and developers are the weather. The weather stays unpredictable, but if it happens to rain the shaman can take the credit, and if the drought remains, it's because the ritual wasn't done _correctly_ , you see. The illusion of control is the product they're selling. What the managers are buying is someone that says "yes, we can have it rain on the 19th" instead of talking to someone that says "we can predict the weather about a day out, maybe"

(God I hope no project manager I work with ends up reading this, heh).

<comment> Fire-Dragon-DoL Stupid question: can't the businessman do its job? I mean, it's not like the market is constant everywhere, they must be dealing with probabilities too.

</comment></comment></comment></comment></comment><comment><USER10> Yep!

 _Considering that the metrics above are still considered viable at the dawn of 2020 proves how much opportunity still remains for managers to improve the measurement - > incentives -> long-term outcomes achieved by their team. To their credit, the instinct that leads managers to utilize these metrics is sound. They know that the best businesses make their best decisions using data. But so much depends upon whether the data is any good. When you place trust in a metric like commit count, you're liable to end off worse than if you'd used no data at all (i.e., by pitting the team against one another).

Our opinion is that a less bad metric would be one that harnessed the signal lurking deep within lines of code, while rinsing away its noise. The metric would consider "issues resolved," but only after normalizing for implementation complexity, so developers that work in front-end systems don't take the lion's share of credit after resolving a myriad of tiny tickets._

<comment><USER11> >> The metric would consider "issues resolved," but only after normalizing for implementation complexity, so developers that work in front-end systems don't take the lion's share of credit after resolving a myriad of tiny tickets.

Only if you are not being rewarded for solving your own bugs. Otherwise, I've seen this go horribly awry.

I was at a Big 5 consulting company where one project was big on "how well you managed issues and brought them to resolution". That meant that good developers who prioritized code coverage and mostly bug-free code did not have good issue resolution case studies to cite during promotion cycles. After a year of good developers getting dinged on this, some good developers banded together to purposefully leave known bugs in the release (especially bugs that could be blamed on vague specs -- so instead of trying and resolve issues during dev cycles, they were propagated to production). Then, the developer would swoop in and do lots of "investigation", produce a fancy write-up and email (carefully cc'ing senior management) and throw the business analyst under the bus.

Senior Management naturally was impressed and some of the developers got promoted for their "leadership" and management of "critical bugs."

Bad Incentives --> Bad Outcomes

<comment><USER12> This is known as the Cobra Effect.

I worked at a healthcare company where the chief architect was considered a genius by upper management because he would dive in and "save" production; in reality he was the cause of all the bugs that broke it but he did not allow anyone to fix the problems.

</comment></comment></comment><comment><USER13> > The longest has taken two weeks and is still ongoing.

Even worse, the typical braindead "solution" to this problem is to insist that everything be broken up into chunks of a few hours or less each before work can begin. The end result is "if it can't be done in a couple of hours, it isn't worth doing".

<comment><USER14> It seems like I have read where "esteemed members of the community" advocate this, at least to enable estimation. Joel-on-software, maybe?

</comment></comment><comment><USER15> Actually, LOC isn't that bad. Studies have shown

        - that complexity metrics are highly correlated with LOC.
        - people can produce & maintain software at about 10 LOC/h. This seems to be a constant of the mind.

It means you're better off doing 10 lines of python than 10 lines of ASM as the 10 lines of python will do a lot more.

Both facts are discussed at length in "Making Software" (Oram, Wilson)

<comment><USER16> > people can produce & maintain software at about 10 LOC/h.

That is shocking and horrifying if that's the norm for software development.

<comment><USER14> I think that people who claim to write many lines of code per hour just don't count small amounts of time lost and don't realize it adds up or feel it _should_ be exempt from counting. It's like the calories in broken cookies, or the ten minutes it takes to get out the door when you only spent a few seconds grabbing a few things.

One thing that I think can give you perspective is if you experience a job where you account for your time like lawyers do, in 6 or 15 minute increments. It's surprisingly hard to get your billable time over 50%, assuming you're honest about it.

</comment></comment></comment><comment><USER17> The 'best' software productivity metric I've ever seen is one I created and tested on a large code base. It only measures coding, but it's better than the other metrics for that. It is based on information theory and credits code removed equally to code added. In the end, I reported the results to the devs and then stopped doing it because there was too much opportunity for abuse by my superiors. Once they got wind of it, they wanted to know everyone's scores and I could see where it was heading.

The metric: It was based on a very powerful (and slow) compression algorithm such that it could measure the change in code. Since it used compression, whitespace, boiler plate, etc had essentially no impact. It was carefully tested by comparing the results against human assessments.

The only clear issue was that it did over-credit mass changes (renaming a root package in a java project which caused all files to be changed). This could probably have been handled by adjusting the scores.

After looking at other metrics (bugs reported, comments on bug reports, code reviews completed, comments in code reviews, etc) it was clear that some people made _huge_ contributions through activities that were ignored by the algorithm, and some people who had great software productivity scores contributed little in these other activities. They were putting all their time into their own code.

FWIW, In the same exercise, I came up with another good metric to identify problematic code (rather than problematic people). That metric used machine learning to find code that needed to be refactored. But that's a story for another time.

</comment><comment><USER18> The only telltale metric of software work that I know is the ratio of time spent making progress to time spent not being able to make progress because of past mistakes made and shortcuts taken.

It's reasonable to consider that the reason that software developers are saddled with such shallow process and tooling metrics is that they themselves don't have any better alternatives to offer.

If we roll over and accept the lowest possible maturity organization and process methodologies like Scrum, then we ultimately deserve what we get.

We have a roll to play, and it ultimately requires stepping up and seeing our jobs as more than mere tool-wielding. Or said otherwise, in the rush to call ourselves "engineers" we've stopped being engineers and stopped even pursuing an understanding of the body of knowledge of engineering (which leads to better grasp of the subject area that comprises process and measurement).

Velocity is a standard we're held to because we didn't step up to provide better standards. And we didn't do that because we didn't believe it was our responsibility to learn about the rest of software development. And in that vacuum, people who know even less than us are left to dictate pseudo science to people who should already be in command of the science.

We have a role to play if we wish to play it. It's not obligatory, but there are real costs to pay when we don't.

There's no requirement or expectation to go above and beyond in an effort to catch up on all the knowledge and understanding we've shed from our wheelhouse. It's totally fine and understandable if we don't. But we also have to accept that nature abhors a vacuum.

</comment><comment><USER19> Is the measure of an architect the number of lines in a blueprint? Is the measure of a craftsman the number of finished goods produced? It seems to me that different projects in the same domain should use different attributes to evaluate success. Why do we attempt to use uniform measures across-the-board? Is it lazy management or does delving deep into project-specific metrics make it hard for large enterprises to compare employees in similar functions? Or something else?

</comment><comment><USER20> Is this operating under the assumption that there is no code review?

With code review, lines of code and commit count become much harder to game. If you try to submit changes with unnecessary whitespace, unnecessary code constructs, or incomplete code, your reviewer will see it and tell you to fix it. Ultimately, trying to increase your lines of code or commit count will come back to haunt you as you spend much more time addressing comments from code review.

<comment><USER4> It's still super-easy to game. Just prioritize all the low-hanging fruit. Got some tickets for increasing the font size or replacing the copy in the privacy policy? Why not do those instead of working on the important but hard to debug/estimate problem of some database transactions being slow, but only sometimes?

</comment></comment><comment><USER21> In order to add value to a dev team as a manager, one must have an intimate understanding of the work developers do. There isn't any value in abstracting away from that work when evaluating the contribution of team members.

"Context, action, outcome" is a sufficiently standardized formalism for evaluating performance (assuming outcomes are measured in terms of business value). Accurately reporting context, action, outcome requires understanding both what devs do, why they do it, and how it ultimately produces business value. There's no shortcut. If your management can't meaningfully do that because they are non technical or managing too many people, or whatever, then they are actively harming your team and should be removed with prejudice.

There is no reasonable way to conclude that devs can be effectively measured with garbage stats. Even suggesting it seriously indicates incompetence or laziness.

</comment><comment> fake-name Actual URL: [https://public.amplenote.com/embed/53SmZouWw5nNyBaJNEe6CSdF?...](https://public.amplenote.com/embed/53SmZouWw5nNyBaJNEe6CSdF?hostname=www.gitclear.com)

I completely don't get this weird iframe for the entire article thing.

</comment><comment><USER22> I'm a manager of ~25 developers (who report through a few leads). I also come from a dev background. IMO metrics are dangerous, but can also be useful. Often I find basic code metrics useful as smell tests, but would never use them alone, wouldn't set them as goals, and wouldn't use them alone to rank performance in a team.

If someone has a very low number of commits relative to others on their team, I'll investigate deeper - review a few Pull Requests, check if they're working on something outside source control etc. sometimes I find problems, other times not.

I'm curious what people think of this approach?

<comment><USER23> I would think this is a common approach. I use the same approach. Scales up to hundreds of developers.

I do generally try to enforce the goal that on any working day there should be at least one commit from the developer. If I notice a developer is consistently missing this metric it usually indicates trouble in the project they are working on or that the developer is just not delivering enough.

</comment></comment><comment><USER24> There's a tendency for "metrics" to evolve into a process where the police give you speeding tickets based on the number of times you opened the passenger-side windows of your car. Oh, and if you get a flat tire it must mean that you should lose your license.

Also, beware of pretty graph summaries that are presented _without_ a healthy list of caveats and follow-ups and further explanations. Beware if no one with management power is asking the follow-up questions that matter.

</comment><comment><USER25> Best software metric: lines of code removed

</comment><comment><USER26> Why not let developers justify their work and point out its positive impact themselves? It would require some overhead, but they could highlight the appropriate metric if it can be quantified and also justify more qualitative improvements.

</comment><comment><USER27> Author concludes (before promoting his product) "The metric would consider "issues resolved," but only after normalizing for implementation complexity", so story points then?

</comment><comment><USER28> Not to get too far off topic but is anyone familiar with how Boeing runs their shop? What's management/leadership like? What metrics they use?</comment>


Audio GIFs - <AUTHOR> http://audiogif.rancidbacon.com/README.html <comment><USER2> The extension seems to arbitrarily follow no existing prior format. For example, tar.gz is clearly a tar file that has been gzipped. But what is a .a file?</comment>


Streaming Video and Audio with Low Delay - <AUTHOR> http://steinwurf.com/blog/2018-04-25-2022.html <comment><USER2> Periscope developed a Low-Latency HTTP Live Streaming (LHLS) technique that relies on HTTP chunked transfer-encoding to stream video bytes as they are encoded at the origin. This is still subject to TCP packet retransmission overhead, but the time-to-first-byte is reduced significantly and leads to less buffering on the client.

Here's a Periscope post about LHLS: [https://medium.com/@periscopecode/introducing-lhls-media- str...](https://medium.com/@periscopecode/introducing-lhls-media-streaming- eb6212948bef)

Most systems that serve HLS media use fixed content-length segments, which requires knowledge of the length of a segment before the first byte can be sent over the wire. So, for a 5 second segment you would need to encode the entire 5 seconds before the first byte can be sent; this does not apply when streaming the segments with chunked transfer encoding.

Incidentally, at Mux we also use chunked transfer-encoding to stream video that is encoded on-the-fly with great performance.

<comment><USER3> I've heard from colleagues that this won't be possible with DASH due to the switch to fMP4 format. One of my co-workers tells me that fMP4 requires the entire segment to be loaded before playback can begin while TS segments don't require this. We've been looking into very small segments (e.g. 1s duration) to reduce latency but I've been interested in the LHLS approach since I first heard of it.

<comment><USER2> Very short segment durations are effective only when latency is more important than quality.

Each TS segment must start with a key-frame, and the GOP size can't exceed the duration of a segment (e.g. one second). Lowering the segment duration increases the frequency of key-frames, which has the effect of lowering the quality you can achieve at a given bitrate.

<comment><USER4> Note that this is a Apple requirement for HLS. Most people don't realize that the GOP size doesn't impact the latency, but it impacts start-up time.

</comment></comment></comment></comment><comment><USER5> Low delay is much, much more important for _calls_ than for streaming. One second of buffering delay may be acceptable in streaming playback (users often contend with longer delays). That much delay will severely degrade a video call, especially if the audio stays synced with the delayed video.

<comment><USER6> Also, for real-life auctions where online bidders can participate

<comment><USER5> There is justification in regarding that as a form of video call rather than media playback, even though the video may be only in one direction and the reverse communication (flow of bids) isn't AV.

</comment></comment></comment><comment><USER7> Instead of a separate protocol you can already use a codec with built-in FEC such as OPUS.

<comment><USER8> Which video codecs have that inbuilt?

<comment> TD-Linux None, so a separate FEC can still be useful. You can use FEC like described in the article with WebRTC: [https://tools.ietf.org/html/draft-ietf-rtcweb- fec-08](https://tools.ietf.org/html/draft-ietf-rtcweb-fec-08)

</comment></comment></comment><comment><USER9> Anybody have an idea how to put this into practice? I recently tried streaming video over wifi from a Raspberry (for a robotics hobby project) , and everything I tried was either unusable or very delayed.

Is there an open source low latency video streaming solution for hobbyists?

<comment><USER10> I use ffmpeg and some custom services for [http://robot247.io](http://robot247.io)

All the code is on GitHub. I can get very low latency video. Most of the delay comes in the form of the speed of light being so slow.

On the web site in use jsmpeg.

<comment><USER11> Can you link the repo please? I couldn't find a link in the site and would be interested.

<comment><USER10> Here is the core of the site. I have not had much time to keep robots on line but if you want a demo you can ping me at my username at gmail and I can pop a robot on line (during work hours if I am in the office).

I have been working on a better web interface that has on screen controls, because most people seem to want to type in like twitch, but the arrow keys are what you use.

[https://github.com/mbrumlow/webbot](https://github.com/mbrumlow/webbot)

</comment></comment></comment></comment><comment><USER12> Anyone know what the best streaming solution for browser <-> browser video calling is? It probably has to be built on top of WebRTC but I'm wondering if there are codecs and forward error correction algorithms out there already in Javascript to use.

<comment><USER13> For small numbers of people in a call (say, n < 5), the "best" \-- meaning lowest latency -- solution is direct browser to browser WebRTC connections. Both Chrome's and Firefox's WebRTC implementations have quite good FEC built in. And sending UDP packets directly between peers will have much lower latency than routing through a media server.

Of course, sometimes peer-to-peer won't work for you. Maybe you have requirements that push you towards routing media through a server. (Content filtering, or compositing video or mixing audio, for example.) Or maybe you have more than a few people in a call. If so, upstream bandwidth and encoding become bottlenecks for mesh/peer-to-peer. Finally, some firewalls won't allow UDP traffic from/to computers behind them, so you'll need to route UDP through a central server, or (much worse) tunnel over TCP.

Back on the subject of latency and error correction in WebRTC, here are some fun links:

Draft spec for FEC in WebRTC: [https://tools.ietf.org/html/draft-ietf-rtcweb- fec-08](https://tools.ietf.org/html/draft-ietf-rtcweb-fec-08)

Mozilla article from when they first turned on Opus FEC. Includes sample audio for calls with 19% packet loss. (19% packet loss is very, very bad. My startup makes a browser-to-browser video calling tool, and we try hard to deal well with packet loss that high, but it's a losing battle.) [https://blog.mozilla.org/webrtc/audio-fec- experiments/](https://blog.mozilla.org/webrtc/audio-fec-experiments/)

Notes from the very knowledgeable folks at Callstats.io about WebRTC FEC. Covers some of the same material as this thread's original post: [https://www.callstats.io/2016/11/09/how-to-recover-lost- medi...](https://www.callstats.io/2016/11/09/how-to-recover-lost-media- packets-in-webrtc-with-fec/)

Tsahi Levent-Levi's benchmarks showing how a few different media servers perform in the context of 10% packet loss: [https://testrtc.com/webrtc-media- server-packet-loss/](https://testrtc.com/webrtc-media-server-packet-loss/)

</comment></comment><comment><USER14> The title is misleading, when they say low-delay, really they mean over UDP instead of TCP. Their answer to video over UDP is a marginal efficiency gain in a forward error correction algorithm called RLNC.

I haven't looked at RLNC, but it does seem to have some gains over more traditional FEC schemes.

[https://arxiv.org/abs/1802.04873](https://arxiv.org/abs/1802.04873)

<comment><AUTHOR> As stated in the article, low delay is very hard to achieve over a reliable transport based on re-transmissions (such as TCP) - you have to wait for the loss to be detected and then the retransmitted packet to arrive. This is at least 3 x the latency of the link. Therefore if you really care about bounded low latency you need to use some form of erasure correcting algorithm (to provide upfront redundancy).

In the article we simply show that substituting one "old" algorithm for a more modern one can give you much better efficiency (protection against packet loss) for the same bandwidth and latency/delay budget.

<comment><USER14> Please help me understand then. I see RLNC compared to 2022 Single mode has the same overhead of 25%. When I compare the two using your tool at the end of the article, the only change I see is an improvement from 5% random loss to 25%. The burst loose stays the same. Correct?

<comment><AUTHOR> Yes, you get a much better random loss protection with RLNC. So if you know that all your losses are bursts you may be able to live with 2022. Essentially the difference between the two algorithms are that with 2022 only a subset of your packets are protected by a redundancy packet (and you have to choose how to protect them), whereas with RLNC you can protect all available packets. If we leave the premise of this post (namely that we want to generate traffic in the same pattern as 2022) RLNC can even protect against longer bursts compared to 2022.

Did that make sense?

</comment></comment></comment></comment><comment><USER15> Anyone know what PSNow/ cloud gaming services use? I'm using it to play some ps3 games and the delay is immediately noticeable when you start playing, but your brain adjusts and it's not noticeable. Has to be around 300-400 ms round trip</comment>


Ask HN: Any pepple smartwatch alternatives? - <AUTHOR> Wanted to buy a pebble time 2 as soon as it would enter stores, which unfortunately never happened. The search for an alternative has left me frustrated. I can not seem to find an affordable smartwatch that has a long battery life, always gives the current time that is also hacker friendly. Any suggestions for a smartwatch that is focused on productivity rather than fitness? Would also love to hear success stories of people who use their smartwatch to improve their life, so I know I am not chasing a pipe dream ;) <comment><USER2> The "focus on fitness" is more about what apps are immediately available by default. The biggest issues w/ smart watches are battery life and hackability.

For hackability there aren't a lot of mass-produced options.

For battery life there aren't a lot of mass-produced options that have a large enough screen (e.g., the Withings Steel HR has decent battery life, but a miniscule display).

Ticwatch doesn't seem like it's up to par.

I think there's going to be a lag before a real competitor shows up.</comment>


Ask HN - How to make an android phone prototype? - <AUTHOR>

It sounds like it'd be fun to get a phone made to my specifications. I'm talking about mainly physical design, I would be fine with taking a chip/board/camera combination as is and just getting the body customized around it. Is there any kind of guide for how to go about getting something like this made? Or are there companies out there that perform this kind of service? <comment><USER2> Do you have a 3D printer? Just spitballing here, but what about printing a case around a phone chip closest to the specs you're looking for?</comment>


Does this tiered SAAS pricing model offend you? - <AUTHOR>

I'm about to launch a niche support app that will be sold on a per user basis. I've been thinking a lot about pricing today, since that is the only code remaining for my MVP. A lot of SAAS offerings charge based on user/agent tiers, and I'd love to know how people generally feel about this.
For example:
$50 - up to 3 users
$100 -  up to 10 users
$200 - up to 25 users etc
I see a lot of companies doing this (Highrise, Chargify, etc). In the above example, the per user cost is all over the map. 1 user is $50/user...3 users is about $17/user... 4 users is $25/user...etc etc.
My gut tells me that the fairest route would be to simply charge per agent. I think it would also be ok to keep the first tier...so $50 for 3 users, then $X per additional user (where $x is less than $17).
Or... do companies prefer to pay on tiers so they can easily gauge their monthly expenses?
Does anybody have any thoughts? experiences? <comment><USER8> My gut tells me that the price should be an analytic function of the number of users or resources used, with an everywhere-positive first derivative and an everywhere-nonpositive second derivative.

Then again, my service has pricing in picodollars, so I'm clearly crazy.

<comment><AUTHOR> I really like the way you view this, and I think the picodollar pricing on tarsnap is fantastic. I just don't know if I have the guts/resources to attempt this!:)

My product requires deep integration inside of other people's software - ecommerce, saas, etc. The majority of customer support will be on the front- end. I'm a two man shop and not able to handle a large support load of customers who haven't paid real money.

Do you encounter this at all?

<comment><USER8> I have unusually competent users, so the support load for Tarsnap isn't very high. I have a deliberate policy of providing the same level of support to everybody even if I know they're only spending a few cents per month -- not just because it's what I would want if I was a customer, but also because I've seen many many instances of "you provide really good support for Tarsnap, now I feel I can go ahead and upload all the rest of my data" turning very small customers into very big customers.

</comment></comment></comment><comment><USER9> It depends on the the service. I use freshbooks, and their plans are roughly based on number of customers you have. I don't mind paying more the more customers I have, because it means I'm making more money. I don't mind spending money when I'm making money.

One thought is that the bigger your customer is, the more they can afford to pay for the service. You don't want to leave to much money on the table. Its pretty normal for people to undercharge for their services. Do you have any feel for if you are going to get more 1-3, 4-10, 11-25 users?

The things I don't like about tiered services, is that there is a big price jump when you move between tiers. Moving from 3 to 4 users in your example doubles the cost to the service. I'd make more gradual tiers rather than big jumps.

</comment><comment><USER10> I'm curious about this as well and was going to submit this question to HN. I'm debating between charging say per $5 per user or like you say a tiered approach:

$7 - <USER2>

$12 - <USER3>

$22 - <USER5>

$40 - <USER5>

$90 - <USER6>

$150 - <USER7>

On one hand a flat fee per users seems to be the simplest approach where as the tiered system implies a deal with more users.

I'm leaning towards the tiered method. Everyone loves to feel like they are getting a deal. I know I do and when I put myself in the buyers shoes I think this is what I'd like to see.

<comment><AUTHOR> Yes this does seem to be a popular choice. From a business standpoint, I like that the extra revenue flows in at the front end of the tier.

With this model, how will you do upgrades/downgrades? Would you prorate the portion of the month on the old plan + the prorated portion of the new plan? Then, continue charging on the new plan the following month?

<comment><USER10> I'm using Spreedly.com as my payment processor. They prorate and either credit or charge the account based on upgrade or downgrading. I've tried my own billing before it was a major pain in the ass.

</comment></comment></comment><comment><USER11> I have similar question as well. I am building hosted telephony app, and the question is whether to charge base fee + telephony charges or bundle minutes into the plan. eg. $9 for basic plan + 5 cents a minute $15 for advanced plan + 3 cents a minute

OR

$15 with 500 Minutes $30 With 2000 Minutes etc.

what are general assumptions? What factors should I consider before making final decision?

<comment><AUTHOR> Hey my app is actually a telephony app too! I didn't mention the per minute stuff in my post because I have to charge for the minutes regardless.

In your second example, what would you do with a user who only used 100 minutes? Will you rollover their unused minutes or is it "use it or lose it"?

<comment><USER11> I have not decided that yet either. Rollover does seem better option.</comment></comment></comment>


Alzheimer's: 'Promising' blood test for early stage of disease - <AUTHOR> https://www.bbc.co.uk/news/health-53567486 <comment><USER2> Both of my grandparents were diagnosed with Alzheimers a few weeks ago. The disease had brewed inside them for several years, but nobody in my family knew they had it until it became severe.

Unfortunately, neither of my grandparents understand how dysfunctional their brain is. They still have the mindset that they are spry 70-year-olds, when in reality they are in their mid 80s and incapable of caring for themselves. We'd like to move them into a nursing home, but they reject the idea because they don't think anything is wrong with them.

I'd like to imagine this wouldn't be an issue had we detected the disease early enough. Early detection might not prolong life, but it certainly makes the transition to death easier for those involved.

<comment><USER3> I watched my father fade away from Alzheimers over the course of 5 years before he passed. Based on anecdotal stories in a support group, we were very lucky that he realized early on that something was wrong and he was very cooperative throughout. Other families in the support group experienced everything from lighthearted denial to emotions running amok.

Personally, I want some solid tests so I can have reliable information to make sure I end my days as myself.

</comment></comment><comment><USER4> My mum was diagnosed with it last week. My gran had it too. Its by far the worst disease I've encountered, it takes away everything that makes a person who they are and leaves them with nothing. The sooner we understand what's causing it and the fewer people have to deal with it's horrendous consequences the better.

</comment><comment><USER5> I have an idea that's been floating around in my head for a while, and I don't know how I feel about it. So I'll float it here with a note that I am not strenuously advocating for the position I'm about to express, and instead wish to have it discussed.

I have the feeling that our modern medical obsession with keeping the body alive for so long is leading to negative outcomes. The rate of Alzheimer's diagnoses increases dramatically after about age 70[1]. In the US, we began to see the _average_ life expectancy increase past 70 in the 1950s, and is now approaching 80[2]. As a result, I think the current crop of people who are alive are among the first to see the effects of truly advanced age. Prior to the 1950s, longer life was always seen as a good thing: you had more time to enjoy relative good health. Since few people lived into their 70s and beyond, we didn't see the "bad things" coming. Now that people are living into their 70s and beyond, we start to see the horrible effects of advanced age. So the question, which again I don't put forward with much conviction: is continuing to put forward the preservation of life worth it given the extreme decline in quality of life that we see past the age of 70? The gut answer is "obviously yes," but I think we are the first people to have to truly grapple with this question, as we watch our elders mentally fall to pieces while their bodies chug along. Is that gut answer just the result of centuries of trying to get past year 70? Now that we're past it, should we re-evaluate? I have a very close relative in his late 60s going through Alzheimer's right now. Would it truly be worse if he had passed away a couple years ago?

I don't know.

[1] [https://en.wikipedia.org/wiki/Alzheimer's#Epidemiology](https://en.wikipedia.org/wiki/Alzheimer's#Epidemiology)

[2] [https://www.macrotrends.net/countries/USA/united- states/life...](https://www.macrotrends.net/countries/USA/united-states/life- expectancy)

<comment><USER6> The key word here is "good health". If you start shifting from "living as long as possible" to "living with the most dignity up until the end", you end up questioning euthanasia, but also how people live post work-life: typically, how people are going to live decently through their last stage post 60s, can they enter a stage where they are relieved from the stress, pain, etc. You can't just say "well let them die earlier" if you don't provide some form of hope of relief for their last years.

Today I'd argue that the growing lifespan is used as an argument to make people work longer, which means in worse physical conditions. The "Work until your death" motto (the curse of people living in poverty) is not great for a healthy and attractive society. Questioning it ends up in a heated political/societal/philosophical discussion pretty quickly. And we're definitely not heading in the healthy direction: not because we don't want to shift the medical institution, but because we need a more profound society change. From a purely economical PoV, it's great that people die before around the beginning retirement, from a societal PoV it's a disaster.

<comment><USER7> People are asked to work longer because pension systems were set up when people used to die less than ten years after retirement and now a lot fewer young people have to pay for retirees living 15+ years. The only way to avoid this is to drastically reform pension systems.

</comment></comment></comment><comment><USER8> The meta-problem is that early identification only matters if we have an effective therapy which can seriously slow or halt disease progression.

we do not.

<comment><USER9> I work in this field and whilst it's true that there is no direct medications that can seriously slow or halt the progression, there are effective avenues for slowing it via diet, exercise, reduction of stress factors: [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5546647/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5546647/)

Early identification absolutely matters, the question is HOW early. 5 years doesn't do much, 15 years? You can change your entire lifestyle and the changes can take effect with that much time.

<comment><USER10> I believe that my mother may be suffering from the early stages of Alzheimer's disease. It seems to have plagued all of the women in her ancestral family lineage, and she is therefore well aware that she will likely inherit it. Because of this she has tried to be as healthy as possible her entire life in terms of diet and exercise; albeit, she's now at the age where these issues may start to surface. Is there any benefit for someone like her to get tested?

</comment></comment></comment><comment><USER11> I watched The Bit Player last week.

[https://en.wikipedia.org/wiki/The_Bit_Player](https://en.wikipedia.org/wiki/The_Bit_Player)

Claude Shannon had Alzheimer's. Nothing protects us from the disease. We should be doing a lot more research into this disease.

<comment><USER12> > We should be doing a lot more research into this disease.

Trying to actually pin down hard numbers is difficult (searches invariably lead you to the cost of Alzheimer's disease rather than the cost of Alzheimer's research), but it looks like we're already at several billion dollars a year on Alzheimer's research. If it hasn't cost more than the Apollo project already, it likely will by the end of this decade.

<comment><USER11> The healthcare costs for Alzheimer's will be in the trillions, if we don't cure it.

</comment></comment></comment><comment><USER13> A friend of mine has a parent with Alzheimers, and he swears the symptoms have improved via tumeric supplements.

He said apparently the prevalence of alzheimers is less in india, where tumeric is found in much of the food.

(andecdotal evidence, but interesting)

<comment><USER14> Life expectancy in India is about 10 years shorter than e.g. the US and other developed countries. As such you'd expect to see far less Alzheimers for the simple reason that most people get diagnosed at an advanced age.

That's before taking into account potential differences in whether or not people are diagnosed.

That said, turmeric (and especially curcumin) is a subject of study. But these studies also suggest it is unlikely simply eating turmeric helps, as it's not absorbed well by the body and the amounts needed would be exceptionally high.

<comment><USER15> That's a great point, but life expectancy is generally highly affected by infant mortality. How's their median life expectancy at 40?

</comment></comment></comment><comment><USER16> Maybe I read the original research article incorrectly, or maybe this BBC piece is discussing something additional, but my impression after reading about it more closely was that this test is actually discriminating Alzheimer's from other forms of dementia, not Alzheimer's vs no dementia.

I haven't thought this through yet but it seems interesting and important but also not quite how it's being portrayed in the media, and not quite as significant in some ways.

</comment><comment><USER17> 96% accuracy may be a problem...

Depends how many false positives and false negatives, but if there's 4% of false negatives and there's, say, 1% of the tested population that has the disease, then even a positive test may mean you have only 20% chances of being actually positive.

(someone double check my math, but the general idea stands, I think)

<comment><USER18> The actual data is more complicated than "96% accurate", but I'm not the best person to deep dive on the numbers and give a better analysis.

However from reading the abstract of the actual study, it seems the TLDR is "more accurate than current ways to test, and significantly cheaper too" \- which would be a great step regardless of if it's not quite as perfect as a vague "high % accurate!" makes it sound.

[https://jamanetwork.com/journals/jama/fullarticle/2768841](https://jamanetwork.com/journals/jama/fullarticle/2768841)

</comment></comment><comment><USER19> A previous article and discussion on the state of Alzheimers research: [https://news.ycombinator.com/item?id=21911225](https://news.ycombinator.com/item?id=21911225)

</comment><comment><USER20> Unfortunate that we have thrown billions upon billions and not a single viable treatment has made it out the pipeline. Truly one of the diseases that has escaped humans, thus far.

<comment><USER21> Age-related mental disorders are the final frontier for the human species.

Heart problems are basically mechanical problems, we're guaranteed to fix them in the next 100 years, if only by printing new hearts and blood vessels. Cancer is a cluster of rogue cells, and just it's a matter of time before we can focus poisons, blades, irradiation, and nano-bots precisely enough before treatment becomes as routine as annual dentist visit. Similarly bacterial infection - it's just a foreign object that needs to be killed with some precision. Viruses are trickier but maybe not that much - killing infected cells seem like it would do the job.

Brains are complicated though, you can't just seek and destroy something that's wrong. It's not a given that we can fix them in the near future, and as all other diseases recede we will end up with close to 100% of people succumbing to brain disorders at the end of their lives.</comment></comment>


Bitcoin miners back online - <AUTHOR> http://createabeta.com/bitcoins-back-up

<comment><USER2> This just gives me more reasons to not invest any of my money in Bitcoin. The market is just to volatile.</comment>


Surprising Uses of the Pythagorean Theorem - <AUTHOR> http://betterexplained.com/articles/surprising-uses-of-the-pythagorean-theorem/

<comment><USER2> I really like the concept surrounding sorting.

It really helps you visualize why you need to separate your lists into smaller piles before sorting if you can, since it takes the same amount of time to sort a 50 element list as it does sorting a 40 and a 30 both.

</comment><comment><USER3> "Throughout our school life we think the Pythagorean Theorem is about triangles and geometry." Some of us still do. What he is talking about is Pythagorean triples. Well, maybe. Energy, for example, does not have to be an integer, so it's not really about Pythagorean triples. What is the point?

<comment><USER4> Hi, you don't have to split a triangle into integers. For example, you could have

50^2 = 25^2 + 43.3^2

Strictly speaking, if you have a circle of radius 50, you can take the sine and cosine of any angle and get a possible way to split the length.

<comment><USER3> Fair enough. Still, what is the point of the article? Some additive quantities are squares of other quantities, you add them, and it looks like the Pythagorean Theorem, without triangles... Is that it?

<comment><USER4> Two main points, mostly to look at this old theorem in new ways.

1) The sides of a triangle (3-4-5) can represent portions of _any_ shape. For example, circle area (radius 3) + circle area (radius 4) = circle area (radius 5).

Instead of radius, you could pick diameter, circumference, or any line segment and the relationship would hold.

2) You can use the Pythagorean Theorem to split any squared quantity into two smaller ones. This can yield surprising insights; is it immediately clear that a list of 50 takes as long to bubble sort as a list of 30 and 40? =)

<comment><USER3> There may be a point here, but I am still uncomfortable with the use of the Pythagorean theorem here. Even if applied to areas only, it seems like a stretch. In fact with this approach one can suggest other identities. For example, if you replace squares with cubes (or circles with spheres), you will have a^3+b^3=c^3. And this clearly has nothing to do with the Pythagorean theorem.

<comment><USER5> You might want to try that math again; it doesn't work for spheres.

<comment><USER3> What math?

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> this is why i surf hacker news...

</comment><comment><USER7> I'm not sure if this was an add, but I got a virus hit from this site.

<comment><USER7> Trying to warn people that an advert is showing up as a virus when you click on the link to this site. How that is worth negitive points I don't know?</comment></comment>


Foxconn shipping new iPads starting late February - <AUTHOR> http://www.electronista.com/articles/10/12/06/foxconns.next.gen.ipad.production.due.february/

<comment><USER2> So has the situation there improved? Are there less suicides? Are the workers being treated fairly?

<http://en.wikipedia.org/wiki/2010_Foxconn_suicides>

</comment><comment><USER3> The original was released on January 27th, so this matches the annual refresh schedule of the iPhone/iPod/iMac lines.

</comment><comment><USER4> FOXCO _NN_

<comment><AUTHOR> Good catch, updated title. Thanks.</comment></comment>


Show HN: make phone calls when you can't talk. I would love feedback on this - <AUTHOR>

Hello,
The idea is to be able to make phone calls when you can't really talk, by using text-to-speech and typing what you want to say instead.
The original incentive was a Twilio contest and to see if that would technically work. Now that it mostly does, I would love to read what you think and in particular if this is actually useful :) (and thus if I should look into ways to make it a "real", even if small, product)
Thanks a lot for your time!
The URL: http://speakforme.timotheeboucher.com/ <comment><USER2> You may have no idea, but, how is speech-to-text these days?

There are several companies who operate call centers for the deaf. A hearing person talks a live agent, who types a deaf person. If the software reached a decent quality, you could offer it directly to a deaf person to use.

Hit up a few sites that cater to deaf people. Make friends. Ask if they'd be willing to test it with their friends and family. And if it works? Sell it to them, or one of the previously mentioned companies, or charge a monthly fee.

<comment><AUTHOR> No I didn't know.

But, at this point, what I built would work for mute people, rather than deaf people, since I don't transcribe what is being said. I imagine I could work something out, but seeing what Google Voice does with this, I'd be surprised if the quality were useable.

<comment><USER2> The thing is, many deaf people prefer to type, not being confident with their speaking voices. Also, most hearing people don't have TDD/TTY machines.

Just a note.

<comment><AUTHOR> _many deaf people prefer to type_

I can see that. It's my understanding that it's common for deaf people to be mute or have difficulty to speak, but they would need to know what is being said on the other end, which I can't quite provide at this time. (though I'll look into it)

 _most hearing people don't have TDD/TTY machines_

I guess you're saying that it could be useful as a TDD/TTY machine on-the-go, is that right?

Thanks for the feedback, I figured that it could be useful in that use-case, and will look into that more.

</comment></comment></comment></comment><comment><AUTHOR> Clickable link: <http://speakforme.timotheeboucher.com/>

</comment><comment><USER3> Great idea if the caller types decently fast. I really wish Twilio were available in South Africa.

<comment><AUTHOR> Good point on fast typing.

Amongst other things, I wanted to add some customizable preset sentences accessible through keyboard shortcuts (e.g. "Hello my name is Tim and I can't really speak right now") as well as a log of what you already said in that conversation (again, with KB shortcuts).</comment></comment>


Steve Jobs and Rounded Corners - <AUTHOR> http://www.folklore.org/StoryView.py?story=Round_Rects_Are_Everywhere.txt

<comment><USER2> this just reaffirms my belief that jobs had a distinct sense of style and taste that far exceeds the normal. I think one of the things that played to his favor that he wasn't so much interested in the "what is possible" and "what isn't", rather he just believed it was possible and inspired technologists/programmers/hardware designers to make it so!</comment>


Holding Companies Accountable For Privacy Breaches - <AUTHOR> http://bits.blogs.nytimes.com/2011/04/27/should-companies-be-accountable-for-privacy-breaches/

<comment><USER2> This is a great line: "If you can't protect it, don't collect it."

Coming up soon: Amazon Web Protection Services

</comment><comment><USER3> Alarmists and lawyers (with help from the panic perpetuating media) thrive in this climate:

" _Christina Gagnier, a lawyer specializing in privacy and copyright, said in an interview last week that there wasn't enough legislation to protect people online._ "

And to hell with innovation, lets make more laws that insure lawyers get paid more.

If things were only depended on lawyers and privacy fundamentalists we would still be living in the middles ages (EPIC contested that Gmail was illegal when launched).

<comment><USER4> Perhaps you've just overstated your point, but could you provide any evidence supporting the statements that (1) stronger privacy laws would cause all innovation to stop, or (2) stronger privacy laws would cause us to revert to a 1200 AD level of technological development.

Edit: To make my point less pedantic: your argument, as you have currently phrased it, is every bit as alarmist as those you disagree with, just in the opposite direction. It's like appealing for calm by calling the people you disagree with whores. At best, such a tactic undermines itself.

Actual discussion:

It is self-evidently true that fines for data breaches would discourage companies from allowing more data breaches. You have countered this by saying such a policy would harm innovation. The snarky response would be that harming innovation in the realm of data breaches is exactly what we want to do. A less snarky response would be to ask you to provide any evidence that investing in proper network security would have made Sony less innovative in any measurable way.

<comment><USER5> He didn't say that we'd revert; we'd simply never move forward.

<comment><USER4> Fair enough. Ignore my second question then. Can you point me to a credible argument for the idea that all innovation relies on privacy breaches, or that only companies who hold customer data are capable of innovation, or some other causal link that would make "strong privacy laws -> no innovation ever" hold?

<comment><USER5> > Can you point me to a credible argument for the idea that all innovation > relies on privacy breaches

Only if you point me to anyone making the case that innovation relies on privacy breaches.</comment></comment></comment></comment></comment>


The Vanity Fair 'Brotopia' party was way worse than it sounds - <AUTHOR> https://medium.com/@paulbiggar/that-party-was-way-worse-than-it-sounds-29f4a3c7e4b8 <comment><USER2> Anyone else find the invasion into the people lives of consenting adults chilling? This feels like a puritanical purge.

<comment><USER3> An official company party is not the private lives of anyone. That's the whole point of the article. It was an official company party.

Edit: for what it's worth, there's also no consent possible when there's an external power dynamic at play.

<comment><USER2> The fact of the matter is, is that for busy high performing professionals their entire personal life is their professional life, but that doesn't mean that their entire professional life is their personal life. This seems to be a case of the former and that distinction was not made clear. Bolding the words "Official Party" make this an official company party. Were people from DFJ there, did they help put this together, were their busses. Yes. Did DFJ's LPs pay for the busses, booze, and catering? Unlikely. Overall I'm seeing an after-hours party of adults and friends. Don't like it? Don't go or leave early. It's sad that this guy had to dox Steve and that we're going in a puritanical direction, just because a small but vocal group of brittle spirits are so easily offended. There's a slippery slope here and while this is where you may draw the line, there's going to come a point where you're crossing someone's line.

</comment></comment></comment><comment><USER4> > Seriously, who has a cuddle puddle at a fucking company party?

West of the Mississippi, there are no rules, or so it seems.

<comment><USER5> Uhh, yeah because Alabama isn't west of the Mississippi and didn't just almost elect a religious and racial bigot, and accused child molester for Senate rather than vote for a Democrat? Sure thing...

Abhorrent behaviors happen all over this country, it's probably best to focus on exposing them and holding people accountable rather than trying to claim these problems happen over there but not in my backyard.</comment></comment>