Ah, the Microsoft tradition of always having the wrong priorities.
I wouldn’t be too hard on Microsoft. The requirement to curate public package repositories only emerged somewhat recently, as demonstrated by the likes of npm, and putting in place a process to audit and pull out offending packages might not be straight-forward.
I think the main take on this is to learn the lesson that it is not safe to install random software you come across online. Is this lesson new, though?
Agile is not a system. It’s a set of principles, set by the Agile manifesto.
The Agile manifesto boils down to a set of priorities that aren’t even set as absolutes.
I strongly recommend you read upon Agile before blaming things you don’t like on things you don’t understand .
the whole point of agile is to be short term
Not really. The whole point of Agile is to iterate. This means short development cycles which include review and design rounds to adapt to changes that can and will surface throughout the project. The whole point of Agile is to eliminate problems caused by business, project, and technical goals not changing because planning is rigid and can’t accommodate any changes because the process does not have room for those.
This is why this whole “things need to be planned” crowd are simply talking out of ignorance. Agile requires global planning, but on top of this supports design reviews along the way to be able to face changing needs. This requires planning in short-medium-long terms.
Don’t blame Agile for your inability to plan. No one forces you not to plan ahead.
The primary problem is using agile all the time instead of when it is actually intended to be used: short term work that needs to be done quickly by a small team that are all on the same page already.
I think you got it entirely backwards.
The whole point of Agile is being able to avoid the “big design up front” approach that kills so many projects, and instead go through multiple design and implementation rounds to adapt your work to the end goal based on what lessons you’re picking up along the way.
The whole point is improving the ability to deliver within long term projects. Hence the need to iterate and to adapt. None of these issues pose a challenge in short term work.
Note that this is failure to deliver on time, not failure to deliver full stop.
It’s also important to note that the Hallmark of non-Agile teams is de-scoping and under-delivering. It’s easy to deliver something on time if you switch your delivery goals and remove/half-bake features to technically meet requirements while not meeting requirements.
I’ve been working with Agile for years and I worked with people who burned out, but there was not even a single case where Agile contributed to burning out, directly or indirectly. In fact, Agile contributed to unload pressure off developers and prevent people from overworking and burning out.
The main factors in burning out we’re always time ranges from the enforcement of unrealistic schedules and poor managerial/team culture. It’s not Agile’s fault that your manager wants a feature out in half the time while looming dismissals over your head.
It’s not Agile’s fault that stack ranking developers results in hostile team environments where team members don’t help out people and even go as far as putting roadblocks elsewhere so that they aren’t the ones in the critical path. Agile explicitly provides the tools to make each one of these burnout-inducing scenarios as non-issues.
it’s about deploying multiple versions of software to development and production environments.
What do you think a package is used for? I mean, what do you think “delivery” in “continuous delivery” means, and what’s it’s relationship with the deployment stage?
Again, a cursory search for the topic would stop you from wasting time trying to reinvent the wheel.
https://wiki.debian.org/DebianAlternatives
Deviam packages support pre and post install scripts. You can also bundle a systemd service with your Deb packages. You can install multiple alternatives of the same package and have Debian switch between them seemlessly. All this is already available by default for over a decade.
I feel this sort of endeavour is just a poorly researches attempt at reinventing the wheel. Packaging formats such as Debian’s .DEB format consist basically of the directory tree structure to be deployed archived with Zip along with a couple of metadata files. It’s not rocket science. In contrast, these tricks sound like overcomplicated hacks.
The Philosophy section has quite a few wonky arguments; I’d skip it altogether.
I agree. I wish they moved that to a standalone section so that it could be easily skipable. Reference docs can and should have a rationale, but a lengthy rant is not what leads people to the site.
This shape certainly beats a triangle (…)
Nature loves triangles.
It might be just me, but I think key bindings should definitely not be easily configurable or even changed across release. They should.be standard, pervasive, and set in stone.
For those who really want configurable key bindings in Firefox I think there are already a couple of extensions that do this for you.
This is a really important principle of making APIs that people don’t really talk about. There’s a fine balance between hardcoded literals and full-gui options menu.
I think this principle might fly under some people’s radar because it has been a solved problem for decades.
Even Makefiles don’t require changes to the file to be configured. They take environment variables as input parameters, an approach that directly and indirectly permeated into high-level build systems. One example is the pervasive use of the VERBOSE
flag.
After all these years I only had to tweak build config files by hand when I wanted them to do something that they were not designed to do. All build tools I know don’t require it. The ones linked with IDEs already provide GUIs designed with this in mind.
Fair enough.
Because you’d have to stash your modifications to be able to switch branch.
OP said nothing about stashing, only committing WIP commits to feature branches. I don’t think none of your remarks apply, because if you really need stuff from the WIP commits you can also cherry-pick them or checkout specific files.
git switch
and git restore
were introduced way back in 2019. I don’t think they count as new.
When you have 1000+ Cypress tests, for example, it takes time to run, plain and simple.
It’s one thing to claim that tests need time to run.
It’s an entirely different thing to claim that the time it takes to run tests is proportional to test coverage.
More often than not, you have massively expensive and naive test fixtures in place that act as performance boat anchors and are massive bottlenecks. Thousands of tests run instantly if each test takes around a few milliseconds to run. For perspective, the round trip of network request that crosses the world is around a couple of hundreds of milliseconds. A thousand of sequential requests takes only a couple of minutes. If each of your tests takes that long to run, your tests are fundamentally broken.
Why do you think test times are proportional to coverage rates?
If anything, I thing Stack Overflow replaced Usenet as the source of informal technical advise.
Never heard of Experts Exchange beyond the jokes.
The report of the bug is not the problem.
People in this thread are arguing otherwise.
The prioritization, (…)
Users filing tickets do not prioritize jack shit. That’s not how it works. At best they mention an issue is important to them. Not even in big corporations dealing with internal tickets things work like that. The responsibility of prioritizing work lies on the project owners, exclusively.
and demand that it be fixed quickly (…
Literally what each and every single user affected by a problem asks in their bug reports.
Again, why do you feel this is something that warrants your outrage?
Running JavaScript everywhere is looming as one of the biggest screwups in InfoSec. What do userscript extensions like Grease monkey teach us?