“The output constitutes many terabytes of data and requires a high-performance computing system to run,” co-author Pawlok Dass, a SICCS research associate, said in the release.”

The largest zip file I see on the zenodo link is 404 MB in size, I’d be surprised if it unzips into anything more than a few gigabytes.

The agile solution of incremental value delivery is a compromise, and can produce good outcomes for functional changes. But agile has unacceptable failure modes when working on infrastructure and satisfying system constraints. Agile can work okay for programmers, but it's not a solution for engineers. Acknowledging, owning, and managing risk is more scalable, but you have to have leaders who acknowledge that they exist and have the maturity to take on that responsibility.

We have a fundamental failure to communicate, what we're doing. The game project managers and finance believe we're all playing is a regression towards the mean, where everything is additive and rounds up to nice consistent formulaic sums. Whereas software development follows power law distributions. A good piece of software can deliver 10x, 100x, or 1000x the cost to produce it (ex: distribution, cost of delivering another copy of software is near 0 once written). You don't get that sort of upside with many other investments. Finance is happy with an NPV 8% above what they invest in. This means that when software people talk, everything they say sounds foreign, and everyone assumes it's because of jargon. It's not. The fish don't know they're swimming in water. When the fisherman comes, everyone is caught off guard.

So we get what the author talks about

> The estimates stopped being estimates. They became safety railings against being held accountable for unreasonable expectations.

We. Pad. Like. Crazy. Yes this is inefficient. Some project managers recognize this. We get theory of constraints. But rather than cull the layers of hierarchy that lead to the padding in the first place, all the blame for failure goes back to developers. Get hit on the head enough and you will stop acting in good faith and pad to save your ability to feed and cloth yourself.

[1] https://www.servicenow.com/docs/bundle/yokohama-it-business-...

I doubt the efficacy of creating mammoth like creatures, or elephants that have mammoth traits. We’re talking about recreating an ice age creature that, ostensibly we hunted into extinction. But with climate change and a warming planet, even if we were successful in recreating mammoths, where would such a creature live? James Hansen, who testified to congress in 1988 and informed the public about climate change, recently said that the Paris goal of keeping warming under 2 degrees Centigrade is pretty much dead. At 2 degrees we’ll be seeing ice free arctics at-least once per decade. With that future, there’s simply not going to be any habitat for these creatures to live in.

The Inflation Reduction Act authorized $370B of spending over 10 years on climate and energy [2]. This is about 0.1% of annual GDP and about 0.4% of what we could be investing to address this. If we spent even a fraction more, we could rapidly convert housing and transportation to electric, make electrical grids renewable, and decarbonization manufacturing, we have the technology to do this. We can do this, the most important thing is to tell others we can, and particularly people with power and influence.

[1] https://phys.org/news/2024-04-climate-impacts-global-gdp.htm...

[2] https://www.politico.com/news/2022/07/27/manchin-schumer-sen...

[1] https://www.a2gov.org/sustainability-innovations-home/sustai...

Comments URL: https://news.ycombinator.com/item?id=42830206

Points: 29

# Comments: 31

Comments URL: https://news.ycombinator.com/item?id=42706687

Points: 2

# Comments: 0

> Koch’s dedication to Deming’s ideas eventually led the company into several sticky situations, not the least being targeted in a Senate Select Committee investigation for oil theft in 1988, a direct result of immense internal pressure on employees as part of its continuous improvement program.

[1]

This is powerful stuff. When you empower people and set a goal, they will do anything it takes to hit that goal, including breaking the law.

[1] https://commoncog.com/deming-paradox-operational-rigour/

To me that sounds like a perfectly rational response to fake job apps. When there exists the possibility of 0% chance of a response for a given application, the only rational move is to minimize the investment of all submissions and maximize the number of submissions.

Recruiters and hiring managers spun it as a problem being inflicted on them because of AI tools and the attitude of people applying, with one commentator writing

> Recent cohorts have been infected with a sense that the job market is nothing more than a game that they need to min-max… The problem is so bad that one company withdrew from partnering in our internal job board, citing rampant LLM-generated applications and obvious LLM cheating in interviews.

On the other side of your argument you have people who see no problem posting ghost jobs, and think it’s a harmless way to boost company morale and increase investor confidence. They see hundreds of “low effort” applications being submitted to them, believe it is a cost being imposed on them, and think it’s 100% a problem caused by the applicants. They see no connection between their behavior and the response they get back from the environment and would see your proposal as absolutely ridiculous.

[1] https://news.ycombinator.com/item?id=42531695

> The central thread here is collective action by principled people who will use copyleft primarily as a tool for rights of users and for the improvement of copylefted projects.

Joint stock companies are about hierarchy and control. Free software is very much not about that. Free software is a syndicalist movement by software developers. Software developers have taken control over computing infrastructure, we develop it on our own terms. We have settled on a decentralized model, which shares openly, without constraint.

People with the hierarchical mindset hate another party taking ownership because that’s something they don’t have control over. They would be happy to have you hunched over a keyboard desperately typing while they bark orders at you, regardless of whether or not that produces anything of value. Linux and GCC are both inspired products that grew in the cradle of copyleft, they are excellent because of their open development. Meanwhile, large corporations are happy silo themselves into unproductive morasses and play ritualistic political games [1].

Copyleft benefits users because it produces better software. Enforcement is the only card to play to make sure that continues. Unfortunately our reaction to licensing has been immature. When asked about licensing, we’re happy to throw up our hands and say “I don’t care about that” (see WTFPL) and carry on with development as if some helpful person from legal will do the legwork for us in exchange for our wonderful output. The fact is, legal is still in the 19th-century as far as intellectual property is concerned, and are happy to respond in a formal and threatening way to anything that challenges their hegemony. We have to work with our colleagues in the legal community, educate, and give them a place in our decentralized world. Otherwise, we’ll just be workers fighting for our slice of the pie in a rat race, commanded by people who are happy with consistent mediocrity. Users will suffer.

[1] http://minimsft.blogspot.com/2005/06/bob-herbold-fiefdom-syn...

Some of my take aways.

* Find your friends and allies on an issue. Got broad agreement on something with your community, adjacent communities, bystanders, and your enemies too! Have lots of meetings, go to other groups meetings. Get meetings with elected officials with your allies. I’d say six people is the sweet spot. Represent as much diversity in those people as possible young/old, rich/poor, etc etc.

* Come to the table with solutions. If you’re seeking the vote of someone for something already in the pipeline, that’s an easier ask than say getting them to introduce legislation. If you need to introduce something, best to adapt similar legislation/ordinances in place someplace else. The more track record a policy has, the better.

* Try to make change as local as possible. You’re much more likely to get meetings with city council members and county supervisors than you are with federal policy makers.

* Build relationships with staff! A lot of elected officials are focused on the connection to constituents, they’re not focused on policy, the staff make things happen, policy advisors are in a pivotal role to advocate. Getting staff on your side is almost required to get policy moving.

* If someone is already doing something, it’s easier to plug in and support their work rather than to duplicate effort. To that end, if you’re looking at advocating on tech issues, my suggestion would be to check out I Am The Calvary [1], which is grassroots public policy advocacy org that grew out of DEFCON.

[1] https://iamthecavalry.org/

This increases the risk on applicants that their investment on a carefully crafted resume/cover letter is time wasted.

Fake job postings punish the behavior you desire from applicants and incentivize spraying low-effort LLM resumes.

If you do not post fake job postings, I applaud you. If you know a colleague who does this, I ask that you have a conversation with them about the damage they are doing to your industry.

[1] https://www.cbsnews.com/news/fake-job-listing-ghost-jobs-cbs...

Nothing succeeds like success. If you are on n attempt, and you are geared up for what you will do for n+2, usually the problem surrenders its self on n.

I’ve gone through “agile transitions” in government contracting, at a high level it starts out with a high concept idea of reducing lead times and increasing productivity. Then directives get handed down through layers of management, the decision is made to adopt Scrum or SAFe™, that gets handed down to middle management, who tailor the process in ways that specifically benefit themselves, and you end up with waterfall done poorly and with extra steps™.

What will happen is that there will be very loose definitions of source code and flexible definitions timing when code is released. If an agency does not want to share, they’ll find a way to evade, and still check off the box.

I responded to this risk by making a meeting. I presented our project schedule, and told my colleagues about their expectations, I.e. if they drop code style comments on the PRs they will be deferred to a future PR (and then ignored and never done).

What we needed is fine grained testing with better isolation between components. The problem is is that our management is at a high level, they don’t see meetings as a means to an end, they see meetings as a worthy goal in and of itself self to achieve. More meetings means more collaboration, means good. I’d love to see advice on how to lead technical changes with non-technical management.

I worked on a project in the defense industry where management gave us arbitrary deadlines with the expectation that bugs could be solved in 1-2 days. To solve any bugs in our system required a rearchitecting that would require two months, there was no way around that. The only thing you could employ otherwise were workarounds that would give you side effects. We got arbitrary deadlines put on us, but no go ahead to commit to real solutions. Implementing workarounds, then fixing the bugs caused by those workarounds in circles for a year. We passed most deadlines without consequence, and discovered all of them were fake. Rather than understand the problem we were solving and execute to real solutions, we were micromanaged by schedule people, and this wasted a lot of engineering time and taxpayer dollars. This was a consequence of the defense industry culture. It’s very top-down and hierarchical. Orders flow down without feedback. If there’s knowledge at the bottom, it’s never integrated.

> Putting challenging timeboxes on projects in a healthy environment can lead to serious innovation and creativity.

The author does concede that deadlines can be bad in toxic environments, but does not offer objective criteria for what is a healthy or toxic environment.

What’s missing from these Parkinson’s laws articles are what is actually happening in the time that is filled. We often hear criticisms of gold plating but that misses the point. The fact is that with any technical implementation, there is risk. What fills the time are risk mitigations. Things like if my api returns an error code, can I make my program fail gracefully. These things improve quality, they improve user experience, they are not understood or acknowledged by PMs and are completely ignored by schedule focused staff.

Risk is not modeled in the Iron Triangle plot in the article. Risk is not understood, or recognized by PMs. As a result, ICs are 100% responsible for managing it.

What makes a toxic environment? When PMs fail to take responsibility over their project. Whenever you’re having a conversation about schedule and deadlines, it’s not going to be informed unless you’re understanding your risk tolerance. Otherwise ICs are left guessing what’s actually necessary, and you get people who think throwing on arbitrary deadlines motivates people. It will waste your customers time and money.