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 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.
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 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?
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.
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.
Well, I think you could say I've worked in games too. [1]
In fact, it's in games that the artists, especially when working with 3d, had the hardest time getting the precise kinds of changes that I would need.
But even in 2d, if they, say, created a sprite, but then left a few pixels non-100%-transparent in the corners of the image, I could ask them to go find those pixels and erase them...or I could do it myself.
And if they don't get them completely erased, then there will still be artifacts on the screen and the texture atlas packing will be screwed up.
Yeah. I've been doing this for a long time.
And no, I don't have much hope of getting artists to migrate. I'm just tilting at windmills.
No company I've worked for in the past decade has told me what kind of computer I should work on. Even the W2 gigs have allowed me my choice of Mac/Linux/Windows. I work for tech-savvy companies, though. I'm sure there are tech-naive companies that force everyone to work on Mac or whatever.
And companies that want programmers who write, say, Delphi or Visual Basic, are going to be getting crap developers, and would be better off porting their software to something more modern. I did some work on a Delphi project to help out a friend, and no, I wouldn't go to work for a company to work on Delphi full-time. They couldn't possibly pay me enough.
But that's my point: Just like they would get crap developers, I would get crap artists. Or extremely expensive artists. Not interested. It would literally be cheaper to pay Adobe the extortion they ask than to try to work with non-Adobe artists.
I'm stuck with CorelDraw X8 which dates to 2016. If they were selling a buy-it-once license in 2020, I wasn't aware of it. I swear they had switched to subscription-only by then? But maybe it happened that year and I missed the last opportunity to buy a permanent license.
Last time I looked at Essentials, it looked to me like they had hamstrung it too much. I don't remember the specific restrictions they put on it, but I didn't want what they were selling. Might be worth another look with the Humble Bundle though.
> I don't know why you wouldn't ask the artist to make the edit.
Have you ... worked with artists? To get them to produce technically precise artwork?
The point would be that sometimes it takes 4-5 turnarounds with an artist to get something exactly right. Something that I, as a non-artist but skilled app user, can do in less time it takes to explain what I need to the artist a single time. So it's about saving my time and not having to pay for hours of artist time for something I can do in 10 minutes.
What I'd like to see is tiered licenses. They're being greedy and I refuse to patronize them. That's what it comes down to. I'm not saying they should be forced to do anything. Just that I don't like what they're doing, and therefore end up having to work around their software rather than using it.
I have a license for the last one they offered for a fixed cost; bought it for a steep discount when the new licenses were the Next Big Thing. But they won't get any more of my money until they offer the software at a reasonable price tier.
> ask them for the files exported into a format you can open
They already do that. That's not the problem.
If the original Photoshop file has 200 layers, and 60 of those layers have effects that use advanced Photoshop-only features, then no other art program can open the source material. Period.
At best you can get approximations of the original Photoshop render if you open the image in another program. But generally what you get is garbage if it's not a recent version of Photoshop.
The point of getting the Photoshop original with the layers is that I might be able to make a tweak to one of the layers and have it re-render a result that is better for what I need. Something that is difficult or impossible if I just have a JPEG.
And asking the artist to do the work in a program that doesn't have all of those features is roughly equivalent to asking a software engineer to use Mac/Windows/Linux (pick one they don't know) and to write all of the code in Visual Basic/Perl/PHP/JavaScript/C/C++/COBOL (pick one they don't know). Yes, technically anything is possible in any environment, but it might take 10x as long and be 100x as painful--with a result that may not be as good due to the tools not being as good.
Artists are professionals with an acquired skill set. You can't ask them to work using unfamiliar tools and expect them to be happy or productive.
I'm a programmer. I periodically need to make a tiny tweak in a file that's been created by a real artist, or I want to edit a photo I took, or whatever.
It's insane to spend $1500, or even $500 (the CorelDraw buy-it-outright price) for hobby and occasional-use software like that.
And yeah, I use other things like Affinity Photo, which is Good Enough for many of my purposes, but it's just annoying to not be able to use the same software as my artists--unless they flatten the image before giving it to me, it's a crap-shoot whether I can import it in anything but the exact version of PhotoShop they were using.
It feels like extortion: I have to pay the artist to make the tiniest changes because I can't edit the original file, or I have to pay Adobe an outrageous sum to do it myself. Lose-lose.
CorelDraw is great, but for years they were also subscription-only. In the last six months or so they finally started offering a single-price license again--at a prohibitive level.
I bought the previous single-price version years ago, and it's so stale that I prefer to use Inkscape, despite the more limited feature set, and I've been using the Affinity suite as a more professional replacement.
Now it looks like they let you buy it again, but at $550, I'm still giving them the finger. Their upgrade price used to be ~$200; I would pay that once ever 3-4 years or so, and consider that a reasonable expense to get a good product and have it available when I did need it. But for $550, I'd need to be planning on keeping it for something like a decade to get a similar value--and it's too much to justify buying at my limited usage level.
All of these subscription services should get over themselves and allow you to rent them for occasional usage for a reasonable amount of money. If I could give them $20 for intermittent (time-limited? operation-limited?) use, with no "auto-renewal", I might do that every time I actually needed the product.
But no, they need to be greedy and demand that you pay for a year of usage in advance (or by using deceptive practices like Adobe above).
I've used Paint Shop Pro, and I really don't like it. I can use Corel PhotoPaint and Affinity Photo, and they're fine, but PSP makes me crazy when I try to use it. I'd almost rather use Gimp.
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?