skysight-inc/HackerNews huggingface dataset:
> Some of the most frequently-mentioned problems with Agile are: Agile ignores technical debt;

This isn't a problem with Agile. This is a problem with the management in your organization. I worked at an org that implemented Agile into 5 sprints. Sprints 1-4 were focused on the business work - things that deliver value to the organization. Sprint 5 was an "IT" sprint, where the developers owned the priorities and had time to fix things like technical debt. This worked pretty well.

> frameworks like Scrum are just “red tape,

Yes, companies need their people to operate in a predictable way. This isn't the wild west - you need to be accountable to the people you report to. These "red tape" processes are just regular checkpoints with various people in the org to make sure everyone is on the same page.

Waterfall had this too, except the checkpoints were every 1 - 3 months.

I think the bigger problem is that some software developers don't want to be accountable to people. They just want to do their own thing, like Joel Spolsky recommends with his staff at StackOverflow. It can work great, in the right environment. But the vast majority of companies do not operate this way.

> programmers are asked to commit to arbitrary estimates and deadlines

This has been as old as software itself. I've been on a waterfall project which had "things that needed to be done" and those things had zero detail in them. Yet I was asked to come up with a "ballpark estimate" by my PM. When I had zero idea what it was about, who it would interact with, etc.

> never get the time to think thoroughly about the features they’re creating.

So add a Spike and give it a two week estimate so you have the time to do whatever thinking / analysis you need to do to come up with a solid plan. Spikes exist for a reason - not everything on the backlog needs to be a feature.
As soon as you start transforming it into actionable items, in a non-working team, you immediately start getting capital-A 'Agile' abominations,

I think we should stop referring to those things as "Capital 'A' Agile" ( which isn't even an actual thing to begin with) and refer to them by their actual name: Scrum, Scrumban, SAFE, XP, Crystal, RUP, USDP, AUP, etc. At least we can try to make the point more clear that when we criticize these things, we're criticizing a specific "thing" and not some catch-all term. Given that there is no concrete methodology named "Agile" to actually criticize.
Giving it a name allows for the process to be codified and differentiates it from other processes.
Two chums join forces to take on a third.

https://news.ycombinator.com/item?id=20409693
Typical agile methods squeeze the max out of developers. You optimize estimates (velocity...), break down the task ahead of time and allocate every developer maximum out. Since the next release is always around, dept and a Sprint without full allocation is never there. Essentially, you transfer an engineer into a factory belt labourer.
The idea referenced in the blog post that sprints are "rushing" developers is just nonsense. At least in every sprint process I've been a part of, the developers are the ones assigning effort (points/hours) to each task. The dev team is free to decide how much padding any task deserves to get the job done right -- and some padding is totally legit and expected.

If you have a large task, one that's either too complex to estimate accurately or with too many unknowns or outside dependencies, you should be breaking it up into smaller tasks.

Developers decide how many points they can do in a sprint, AND they decide how many points each task gets. There's no rushing involved here.
Are you proposing software to automatically detect flaws? I don't think "minimum security solution" sounds great. Security should be tested per case. I can't see a any software detecting everything without having ridiculous levels of access.
>(we know that current rehabilitation methods work well for some crimes and not for others)

Somewhat off-topic but I find this interesting, can you elaborate on which ones we know this for?
I'll bite. Management always seem to get the crap. To summarize, if engineers knew how to manage things better than management, why don't they? From my experience, teams without management seem to complain about that and end up with bad results. There are more factors at play, and honestly it's very rare that the engineers sees that (or even acknowledge that they don't know all the relevant factors, with all the implications that gives).

Of course, just as with engineers, there are good and bad managers. But it seems pointless to always complain about management being the ones screwing it up all the time.
not sure if thinking of the solution ('advancing the state-of-the-art) is appropriate yet. Two questions to ask yourself:

1)how well do you understand your customers (are you your customer)? Have you talked to at least 10-20 potential customers to understand what their big problems are?

2) Why do you believe that 'advancing the state-of-the-art'
is needed to solve a meaningful problem? Maybe there's an easier problem you can solve for them, use the opportunity to learn and iterate.
looks like CTEs also support materialization which most devs thought implicitly happened anyway, but didn't. by removing the fence _and_ supporting materialization CTEs are now useful.
Not for the people of Hong Kong.
Another downside to the WASM approach is they'll need to allow unsafe-eval in their CSP to support it on Chrome.
What is the Latin root of this word "gentaculavit"?
Exactly, here are the principles of agile:

-- Value individuals and interactions over processes and tools
-- Value working software over comprehensive documentation
-- Value customer collaboration over contract negotiation
-- Value responding to change over following a plan

That doesn't sound like "agile" anywhere I've seen it implemented. The issue is that you need real buy-in from all levels of the company for any process. I've always said that a "bad" process executed consistency and with real buy-in will outperform any "good" process with only lip service commitment.
Pretty unlikely that Facebook is allowing programmers to name this type of thing.
I will say, as someone who's live in both southern and northern US states...

- Northern "American" food traditions tend to completely lack seasoning of any sort (note: not including appropriated ethnic traditions here)

- Southern "American" food traditions tend to heavily season vegetables (often with ham)

Essentially, if you just took raw vegetables and steamed them, nobody would bat an eye in New England.

In the Southeast, nobody would eat them. And it would probably be politely suggested that you never bring food to the church picnic again.
Sprints are less about categorizing the incoming work, but partitioning the outgoing work, to establish a quick feedback loop. This should in theory ensure that risks are tackled early.
So Jira?
>...problem is that often developers and management (at all levels) give very little thought into "delivering value"

That sounds like a cultural problem. From my experience, tools do not solve cultural problems. Leadership changes cultural problems.
So if you can't use Agile, what is the way to manage software development?

There are many industries with complex product design processes, which need to deliver at a fixed deadline. We expect Apple to deliver new iPhone every fall, and they meet their deadlines without exception. Same thing for many other product manufacturers.

There is no reason to assume software development is very different from other industries regarding product design. Other industries also work with changing and innovating semi-finished products, components, and new materials.

Donald Reinertsen has written some interesting books on managing the design process (not related to software development or agile). It offers a lot of theory and economics behind product design processes. A lot of focus on reducing the size of Work in Progress.
It's not very random. The galaxy also formed from a clump of rotating gas, and this heavily influences the direction all of the sub-bodies will rotate and orbit. Systems influenced by other forces would be the exception to the norm.
The Datadog TUF + in-toto implementation is discussed in more detail here[1]. Let me know if you have questions!

[1] https://www.datadoghq.com/blog/engineering/secure-publicatio...
I'm not surprised that there are vast numbers of latent low-probability race conditions in the linux kernel or any major software project. Having seen the testing process in both hardware and software projects, the two are not even comparable. The testing process in most software projects is dominated by fully deterministic unit tests that are very simple in nature, and make large numbers of assumptions about the behaviors and interactions with other components. Low-probability race conditions between different components is exactly the outcome I would expect from this testing process.

https://software.rajivprab.com/2019/04/28/rethinking-softwar...
The entire category of ideas that agile occupies is utter bullshit, and the alternative to bullshit is just common sense. Hire good people, give clear instructions, and leave them alone. The problem with common sense is that you can't make six figures peddling it for a living.
5 Famous Personalities Who Overcame Failures Before Becoming Successful
CPP, CORBA, XMPP, SOA, UML, Agile... Whenever I've seen the developer community embrace a new set of tools (whether hw, sw, process, or a mix), I've then then the marketing departments and consultants follow. After a period of time the term for the new tools is muddied beyond recognition as people who don't truly understand it try to use it in sales pitches and class materials. In my experience the tool is rarely to blame (maybe I'll make an exception with CORBA, ymmv). The 'Agile movement' started with a bunch of developers who were good comparing notes on their processes. They came up with some points of commonality, and some points from one or more of the others they'd each like to adopt. These all revolved around the engineering version of the unofficial USMC motto "Semper Gumby", always flexible. Some call this the agile mindset (ycmv, i.e. your caps may vary).

"If I have an organization with an Agile mindset, and really rock-solid product management, Agile processes and tools will evolve out of that. If you have the Agile mindset and an awesome connection with your customers and are solving their problems, things will evolve in the right way" - Todd Little, CEO Lean Kanban.

Over and over, people like Kent Beck have said that no one set of tools will work for everyone. Teams need to continually adapt, continually learn, continually improve, and do what's needed to enable those things.

I love the agile mindset, and the palette of tools I can choose from to paint a development process for a team that fits the way they work, their needs, and their customer needs.

OTOH, I hate the "Agile this. Agile that. You got to get certified in them all" Pokemon-style consultant sales pitches, and feel sorry for those who get sucked in by them, or who have managers who get sucked in by them.
I think it is supposed to be generated automatically.
Someone (I think possibly John Cutler) made a good point about this, which is that by now the early and middle adopters of classical manifesto-style "Agile" have absorbed it so thoroughly that it's no longer something deserving of a special term, it's merely the way things are done.

This leaves the late adopters, and the sociopaths whose main interest is extracting money from the late adopters. As a result, it's becoming a safe bet that anyone using the word "Agile" unironically is either going to inflict upon you whim-based development with added Post-It notes, or sell you an enormous slab of process binderware with bonus added two day certification courses. (From which your managers will return having spent the entire course answering e-mails on their laptop, and proceed to inflict upon you whim-based development with added JIRA.)
Prototype: Bus Pirate/Logic Analyzer with Ice40 FPGA
The question was asking about prep work that could have been done. Now is the time to print out some modem pools and get an account ;)

However, if you know someone technical out of the country, you can call them and ask them to set something up and get you the details. (Or you can't call them, and there you go).

If you're talking with people on things like Signal or WhatsApp, where phone numbers are user ids, you automatically know their phone number to call them in case the chat service is unreachable.
I have Airpods and a set of Sony bluetooth noise-cancelling cans and I do not miss a corded headphone whatsoever, I don’t get what the big deal is here
The article focus on latency spikes, which happen only sporadically. Can anyone more knowledgeable on the subject chime in and comment if this comparison is fair or relevant? Personally I was expecting to see histograms or empirical distribution functions of each service's latency.
And what did marching through tear gas give us? More interventionism in South America and... Ronald Reagan?
Agile manifesto is not something you can follow. It is good feel motivational text that outlines goals.

It is not management manual nor specific.
I am not sure it would even save the situation. Most agile methodologies assume a lot of constants to allow measurements to have any sense at all (for instance scrum assumes teams members are stable, of that knowledge over their work perimeter is good, etc.)

We work in a field where inherently there are unknows, and measuring the unknown is not gonna be that useful, however we turn it.
It's very upsetting how quickly the West is abandoning the ideal of free speech.

20 years ago I would not have believed it was possible that we would have a significant fraction of educated people who were opposed to free speech. But here we are, where a book defending the idea of free speech is too dangerous for a publisher to touch.

I noticed this got flagged off the front page for a while. I wonder why. Thank you to the admins for restoring it, at least. (Update: flagged again. Nevermind.)
Eating up post-it notes ("issues") and crapping out code - i.e., doing agile - is just not gonna cut it.

When the end goal is a robust, resilient system that customers depend upon to suit their needs and your organization depends on for its business, by doing Agile you're going to end up with something that neither your customers nor business can fully rely upon (once your system or service is past a certain level of complexity).

Two major reasons:

1. A set of agile "Issues" (whether stories or bug reports) do not constitute a necessary or sufficient set of tasks necessary to produce, release, and operate a resilient or complex system.

2. You know the phrase that "Not everything that can be counted counts, and not everything that counts can be counted"? Agile gives you utterly meaningless metrics (e.g., story points) that can be counted, but don't count. What does count depends on the nature of your business or product: Small start up? Probably revenue or users. Large-scale infrastructure system? Maybe average latency or uptime. Unless you can directly correlate "story points" to your bottom line, just skip that clutter in the first place.

Call me old fashioned, but I found that when you bring engineering back into software development, specifically systems engineering (not "engineering" in the sense of "I'm a ruby-on-rails engineer"), products and teams are able to support a high level of confidence and reliability in their work products. This means (yup) requirements engineering and analysis, QA, Independent Validation and Verification, etc etc. It does not mean you have to have full departments for each of these, but at least having someone to "own" each of these areas (esp for small teams). Again, in the end, no amount of stuffing post-it notes down your developers throats will replace old fashioned engineering process and engineering management.
My favorite response when Product Managers bring up that business needs to know when a feature will be done is "And I would like to know Apple's stock price in 6 months."

I really believe this accurately communicates how difficult it is to estimate software development timelines. You can't estimate unknown work, and unless you're building wordpress blogs, your work in software is unknown.
Maybe he already spent $5m on wedding preparations for his offspring while it turns out that the spouse has the same biological father.
De facto voting rights for African Americans, desegregation, and women's rights to control their own bodies.
SCRUM is toxic. It is toxic because it dis-empowers the developers who are doing the actual work and hands that power over to the "SCRUM master". The SCRUM master is the ultimate bureaucrat -- and a proxy for Management -- in a heavily bureaucratic methodology. The job of the SCRUM master is to guard and protect the SCRUM process. Often to the detriment of the developers and ultimately the project.
> i've been doing no cows and pigs since 2015 and the hardest part is the social aspect of going out with friends and someone announcing to the group, OH HEY THIS PERSON OVER HERE DOES NOT EAT 100% OF EVERYTHING

It sounds like you’re lacking some supportive and understanding friends :( Would they say the same if you had a food allergy?
I think you captured my post better, so I'm just doing it as a reply:

---

"Agile" is like "xml" (or JSON.) Just following a process, or using a technology, doesn't mean you'll do it right. I'm sure plenty of us have come across hair-brained xml, or JSON, that looks like it was designed by a moron.

The same can be said for "Agile." Just because a group tries to follow it, doesn't mean that they follow it correctly or manage themselves the best way.

I'd also like to point out: All of the quote in the article could equally apply to waterfall, or any other software management model.
>Threads is a standalone app designed with privacy, speed and your close connections in mind.

I dont believe you FB. Prove it! This all clear text or there encryption?
The failing after every step has been when they close the loop. That is, agile is used to score and measure velocity. This velocity is then used to impact future scoring. This nullifies Agile's use for measurement since management is now insisting that x number of points be completed per developer per sprint.

The places I've had it succeed greatly have all been new development. We consistently scored stories. Product owners could then had a budget equal to the team's velocity to purchase from the backlog into the next sprint. What it really looked like was they got to arrange the order that the backlog would be picked up and how much would get done in a sprint was an estimate, but with consistent implementation it became eerily accurate over time. It has been my observation that it takes about 6 sprints to calibrate -- where the team scores consistently and the variances from sprints cancel out.

Another point of emphasis is that velocity is a team score. Every failing effort I've been involved with used it to score individuals which inevitably ends up in scoring the stories higher so that an individual gets more points. It also results in cherry-picking easy points and ignoring tasks and bug fixes which may result in zero. It also (like bug fixes) results in everything being assigned points such that points become a proxy for time. If you're developing a new system and you have a bug fix, the team has already claimed the points for that bug fix. You should not make more points for the bug fix, your velocity should actually go down, giving a more accurate estimate in the future of how much new system is actually produced and not a measure of how much a programmer has worked.

So, measurements should absolutely be available to management. But they shouldn't be used to impact future scoring.
Seems completely broken in Firefox and Safari, and mostly broken in Chrome/Chromium - just what browser does the site work with?
The Agile manifesto is absolute bullshit. It's a piece of rubbish which should have never been created.

Here's the true Agile Manifesto:

1. Sack all your product owners and scrum masters, because they are useless and a waste of the salaries which they get paid.

2. Reduce a development team so it's no more than 5 people.

3. Give them god admin access to everything they need to run the show (cloud, CI, dev tools, etc.).

4. Tell them what you need

5. Get out of their way until it's done.
The whole point is that phones are playing "a much more significant role" in the protesters lives than yours. You live in a place where you don't have to worry about that, but what does that have to do with the article??
Is there a name for this kind of chart? It doesn't seem to be a scatterplot in the traditional sense because the axes aren't on a regular interval (If you look at adjacent phones the difference in prices aren't even).

Its more like a scatterplot with a grid overlay?
1) do you mean to imply all languages are equally parseable?

2) You’ve never worked in a company where a bug brought down prod and an on-call has to fix it?
> this criticism suffers from the no-true-Scotsman fallacy

It really doesn't. Most of the things people hate about capital-A Agile are things that specifically go against the agile manifesto.

Take a look at the Scaled Agile Framework (SAFe):

https://156s6k36aesz1w6oyx474wo9-wpengine.netdna-ssl.com/wp-...

It's an atrocity of an overbearing bureaucracy created by a committee of consultants that obviously fetishise process.

Take a look at the agile manifesto:

http://agilemanifesto.org

Its very first principle is:

> Individuals and interactions over processes and tools

Take a look at the rest of the principles and compare them to that diagram. SAFe is clearly the opposite of agile. It calls itself "Agile", but it's as non-agile as is possible to get.

What we have here is not the no-true-Scotsman fallacy, it's somebody rightfully pointing out that somebody born in Australia, who has never left the country, with no heritage that comes anywhere near the northern hemisphere, is not, in fact, Scottish.
Stories we think the community might like. If we guess right, they get time on the front page; if we guess wrong they soon fall off.
To make this comment readable on mobile:

It would have been fascinating to study Japan in the 80's, but now really sure they are still "self-sufficient."

Japan's auto industry is still strong, but their future largely depends on impending trade deal with Trump. Their tech/semiconductor industry has been in decline the past 30 years and what little remains today are being sold to Chinese/Taiwanese companies bit by bit. Japanese brands like SONY or Panasonic now accounts for less than 10% of the US market now, replaced by mostly Koreans like Samsung and LG in high-end, and by Chinese by TCL in low-end markets. The consumer camera business is still dominated by Japanese companies, but the business itself is in a crisis as the market, which peaked in 2013, continues to dive by 30% - 60% annually last several years.
So what? What’s missing is that unless something depends on the ordering of those ids, it really isn’t a race condition. Just plain happening of events is the inevitable passage of time, not a race condition. What is interesting about what happens downstream with those IDs?

You’re not wrong that not all race conditions are harmful, but i feel you’re doing a pretty bad job of explaining what a race condition is.
Given that Linux now has both file descriptors, and process memory-page ranges, pointing to anonymous allocated memory regions, are they interchangeable?

What I mean is:

- to go from a memfd to anonymous memory, you can call mmap(2) on the fd

- to go from anonymous memory to a memfd, you...?
The outgoing product is nevertheless fully determined by the incoming work being done. It would make more sense to group a set of tasks into a deliverable than a time period. You have to do that anyway to deliver anything coherent.
The word 'thread' has existed since long before computers.