No, and Jeffries' analogy suffers the same strawman fallacy.
The proper analogy would be if no one knew the rules of football/baseball and everyone ended up playing Calvinball instead, then you could say that football/baseball was broken. If following the rules of football produced a product of its own if the rules were followed, it shouldn't matter that other people can follow those rules better.
Or you can point at Monopoly and the fact that so many people destroy the game by playing the "Free Parking gets the kitty" rule and use that as an excuse that Monopoly is a terrible game. Well, Monopoly is a terrible game, even as designed, so that one works.
It's not about how well people follow the "rules" of agile. It's that most everyone who tries doesn't understand the intent of agile.
I would argue that most of the attempts at codifying agile, from Extreme Programming through whatever the latest fad is, are all also wrong. That if you codify agile at all, you're missing the point.
In my experience, the OP article is correct: You need good developers on the team. That's it. That's the secret to success. The methodology you use is nearly irrelevant, though some methodologies do more harm than good.
The fact that XP's flagship project (C3) was an abject failure should have been a clue that maybe it wasn't as good as people want to believe it is. Maybe Kent Beck wasn't "doing agile right" either?
Ha. Just did almost exactly that, but with a Go script--I wanted my Docker Compose to auto-update when I built on my CI server.
I found Watchtower, but polling just struck me as the Wrong Answer. Both too much overhead to keep pinging for the latest builds, and too slow to actually download the latest build. So I took some hints from Watchtower as to what I needed to do (mount the docker sock as a volume) and wrote a tiny Go server that, when pinged with a shared secret, would cause it to run `docker compose up -d --pull always`.
Probably took me an hour.
Then I added the ability to purge images before each update, because my tiny VM kept running out of disk space in the Docker partition. Oops. Scripts FTW.
I was already using the suggestion in the article about having a single reverse proxy server to redirect different paths (and different domains) to different servers hosted in the Compose file. Seemed like the obvious answer.
And I've configured k8s for my day job, so I could be using that. But I'm using Compose because I know how much of a pain k8s can be, especially around upgrades, where it has a habit of deprecating older versions of various interfaces. I'll put in the work for someone who's paying me to do it, but I'd rather work on my side project, not on configuring k8s.
> I found Watchtower, but polling just struck me as the Wrong Answer. Both too much overhead to keep pinging for the latest builds, and too slow to actually download the latest build. So I took some hints from Watchtower as to what I needed to do (mount the docker sock as a volume) and wrote a tiny Go server that, when pinged with a shared secret, would cause it to run `docker compose up -d --pull always`.
Is the code for this public? I had the same desire when setting up the server for my personal project but as you mentioned I eventually decided it was OK to just poll every two minutes and I would rather work on the project than on configuring docker. What I would like though is cleaning up the older images that are no longer needed.
Funny that you should say that. Just met with a group of very senior engineers today and two of them said they weren't using VS Code any more. Instead they used:
I'm still on VS Code myself. Cursor at least is just a fork of VS Code with AI features, so you can still use VS Code extensions, so it's something I might try at some point.
Zed sounds cool (it's fast; the guy who used it said it made him feel like he was programming in the 90s again, and I know exactly what he means), but I love having all the extensions (a quick search finds no Tailwind extension for Zed, for instance, and I'm really loving the Tailwind autocomplete). Might give it a try at some point, but I doubt I'll change to it.
Thing is, I was one of those people who kept jumping to new editors. Every single time it was because the current editor had a serious problem of one flavor or another--and another editor solved that problem.
VS Code is likely to be Good Enough for a long time. Zed might gain some adherents like the guy I met today, but I didn't keep trying new editors because I was "on the modern train," but because every other editor sucked in one way or another. All the vims and emacs variants suck. This shouldn't even be a debate, to be honest, but they do suck.
If VS Code keeps on its current trajectory (i.e., Microsoft doesn't abandon it), it will likely be the Good Enough editor perpetually. It's already 9 years old and it's still the "modern editor" of choice. And when I suggest people try a modern editor, I didn't even really mean VS Code but really any editor that's modern. Sublime, Atom, Visual Studio, any of the JetBrains editors...anything modern is better than vim or emacs. But some folks trained their fingers and don't want to change. Nothing you can say to them to convince them.
As another comment points out, Shakespeare is written in "modern English." It's not about chasing the "modern train" as much as not continuing to use Atom or Neovim when everyone else is using VS Code, and VS Code has become the common IDE of the work environment, is already set up to debug the app everyone is working on, and has all of the extensions everyone needs to be on the same page.
I saw some code in a job I was just starting where they had added several abstractions that I found...confusing.
After taking an extra long time to understand what the code actually did, I realized that some junior engineer had been using some design pattern they didn't really understand, and that added zero actual value to the routine.
After deleting all of that code and refactoring it to use completely different abstractions, everything was suddenly much easier to read and to extend.
Design is a hard skill to learn, and junior developers profoundly haven't learned that skill yet. But that's what we need to teach them as senior engineers, right?
Not that I could teach the author of the code I changed, since I think it was written by an intern that no longer worked for the company. But you do what you can.
> I realized that some junior engineer had been using some design pattern they didn't really understand, and that added zero actual value to the routine.
£3.50p says it was the Generic Repository pattern implemented over Entity Framework dbContext, right?
--------
Speaking of design-patterns, I subscribe to the opinon that _Design-patterns are idioms to work-around missing features in your programmign language_, which explains why Java has no end of them, and why us jaded folk find happiness in modern languages that adopt more multi-paradigm and FP (the post-Java cool-kids' club: Kotlin, Rust, Swift, TypeScript, (can C# join?)) - so my hope is that eventually we'll have a cohort of fresh-faced CS grads entering industry who only know-of Facades/Decorator/Adapter as something a language designer does to spite their users because any reasonable compiler should handle interface-mapping for you - and the Visitor-pattern as a great way to get RSI.
I can't even remember the details. It's like trying to remember nonsense sentences; they don't stick because they don't really make sense.
To the best I can remember, it was something like the use of an adapter pattern in a class that was never going to have more than one implementation? And it was buried a couple layers deep for no particularly good reason. Or something.
And yes, modern languages like the ones you list make many of the original GoF Design Patterns either absolutely trivial (reducing them to idioms rather than patterns) or completely obsolete.
FP has design patterns too, just different ones, and they don't all have tidy names.
Also some GoF design patterns map pretty closely to FP equivalents... pattern-matching on ADTs + traverse/fold + ReaderT ends up looking a lot like the visitor pattern.
There is also the fact it’s much easier to write something when you know where you are going. When you start you often just make lots of items general in nature to improve later on.
As someone in leadership, my ‘strong opinion held loosely’ on this, is that there’s absolutely no way to meaningfully build this skill in people, in a theoretical setting.
You can, at best, make them aware that there is such thing as “too much”, and “the right tool for the job”, and keep reminding them.
But nothing, nothing, comes remotely close to the real-world experience of needing to work with over-engineered spaghetti, and getting frustrated by it. Especially if it’s code that you wrote 6 months prior.
Juniors will always do this. It’ll always be the senior’s job to…let it happen, so the junior learns, but to still reduce the blast radius to a manageable amount, and, at the right moment, nudge the junior toward seeing the errors in their ways.
I am actually surprised that there are thousands of people working on Alexa.
WTF are they all doing?! It's pretty much unchanged from the outside in any way that's relevant to me compared to where it was in 2014. And the few changes I've noticed have been things breaking.
I used to, for instance, have a script (I forget the Alexa term) that would turn off a few lights and then play a Pandora radio station when I gave it a "bedtime" command. Worked great for about a year, and then the Pandora plugin suddenly refused to take any combination of commands that I could figure out to play a particular Pandora station in my account. This is true from outside of the automation as well, by the way. It's just completely broken.
The weather app integration is annoying too. I wanted weather to use a different weather source, and instead of just giving me results from that weather source, it would always preface it with "Weather from BlueSky" or whatever. Maybe it's their fault and they wanted the ad blurb? But as a consumer, it sucked. I just wanted more localized weather, not an ad every time I asked for the weather.
And the "AI" behavior of the app...it was just awful. I could get better answers from Google Home devices across the board. The best Alexa would do if I asked it a question is to read the first paragraph of a Wikipedia entry, and it was about a 1 in 4 chance it would actually choose the correct Wikipedia entry.
OH, and don't get me started on the Android Alexa app (!!!). Again, the most major change was a UI update where the most important feature I ever use was hidden behind another layer of menus for no particularly good reason. And the "Kindle Accessibility" feature of reading Kindle books is so flaky I doubt anyone on the team ever uses it, from random pauses to sudden jumps back to read from the beginning of the section of the book you started on 10 minutes ago, looping forever on those same 10 minutes.
Sorry. I know it wasn't your fault. But I finally gave up on using Echo devices, and the only reason I still even have the Alexa app on my phone any more is so I can have it read a Kindle book while I'm driving, and it's so amazingly frustrating to use that it would likely be better if it didn't even exist. It's more "customer frustration" than useful.
You could argue that it was a C++ mistake. It makes parsing harder, but otherwise seems to work as expected, so I don't consider it a mistake, but you could at least argue that way.
But regardless if it was a mistake in C++, it's now a complete standard, used in C++, Java, C#, and other languages to denote type parameters.
I would argue that it would have been a mistake to break that standard. What would you have used, and in what way would that have been enough better to compensate for the increased difficulty in understanding TypeScript generics for users of almost every other popular language?
It's definitely the right choice for Typescript. You could have gone the Scala route and used [] for generics, but that is so heavily used in ts/js as arrays it would not have made any sense.
As long as Node understands to use the project-specific version of TypeScript (i.e., the one in node_modules or the PNP equivalent), that should be fine.
But it would be a step backward to need to globally upgrade TypeScript (as you do with npm), since some older projects will not be compatible with newer versions of TypeScript.
At first I thought that's not a big deal, I could manage that with `nvm`. But I think you're right, you really want it to pick up the project-specific typescript so that you're using ONE version of typescript for type checking, execution, and more.
I couldn't agree with the article on almost any point.
One additional point: You can get "mildly dynamic" websites by using services. I have a completely static web site that's 100% on a CDN and that I've written zero lines of code for...but it has a full dynamic comment section due to Disqus integration. My "how many people have visited my page" is handled by Google Analytics. Other similar embedded services can provide many of the most common "mildly dynamic features".
I'm using Astro on a newer project, which allows you to static-generate pages however you like, but also allow you to run just one component as JavaScript, you can, without the inherent danger of running code on a server every time someone hits your web site. For full heavy-dynamic pages, you can render on the server as well. It's a nice compromise IMO.
That and I never want to use PHP again. Especially Drupal. I liked Drupal at first, but I never want to see it again.
The one that comes with Node? Duh. Or just `npm update -g npm` to bring it up to the latest.
> ...a dependency that only works on node 3.14
So I know you're making crap up now because there was no such version. Node jumped right from 0.12.x to 4.x, as a result of a fork and associated project politics. [1]
And I've been working with Node projects for nearly a decade. I don't see "only works on older-verion-of-Node x.y" almost ever. You're thinking of Python and Ruby.
`nvm` exists because, yes, sometimes you want to run an older project in its exact environment. And it's super easy to install new versions or test under different versions Just In Case there's an issue. Sometimes newer releases only work on the latest Node, so you need to upgrade Node to update to the latest-and-greatest.
But frankly it's worth using Node (and TypeScript) just to not have to ever touch PHP again. It was an is a nightmare fractal of bad design. I'm never going back.
The proper analogy would be if no one knew the rules of football/baseball and everyone ended up playing Calvinball instead, then you could say that football/baseball was broken. If following the rules of football produced a product of its own if the rules were followed, it shouldn't matter that other people can follow those rules better.
Or you can point at Monopoly and the fact that so many people destroy the game by playing the "Free Parking gets the kitty" rule and use that as an excuse that Monopoly is a terrible game. Well, Monopoly is a terrible game, even as designed, so that one works.
It's not about how well people follow the "rules" of agile. It's that most everyone who tries doesn't understand the intent of agile.
I would argue that most of the attempts at codifying agile, from Extreme Programming through whatever the latest fad is, are all also wrong. That if you codify agile at all, you're missing the point.
In my experience, the OP article is correct: You need good developers on the team. That's it. That's the secret to success. The methodology you use is nearly irrelevant, though some methodologies do more harm than good.
The fact that XP's flagship project (C3) was an abject failure should have been a clue that maybe it wasn't as good as people want to believe it is. Maybe Kent Beck wasn't "doing agile right" either?