This presumes that it will be real humans that have to “take care” of the code later.
A lot of the people that are hawking AI, especially in management, are chasing a future where there are no humans, because AI writes the code and maintains the code, no pesky expensive humans needed. And AI won’t object to things like bad code style or low quality code.
I think this is where we lose a lot of developers. My experience has been this is a skill set that isn’t as common as you’d hope for, and requires some experience outside developing software as its own act. In other words, this doesn’t seem to be a skill that is natural to developers who haven’t had (or availed themselves of) the opportunity to do the business analyst and requirements gathering style work that goes into translating business needs to software outcomes. Many developers are isolated (or isolate themselves) from the business side of the business. That makes it very difficult to be able to translate those needs themselves. They may be unaware of and not understand, for example, why you’d want to design an accounting feature in a SaaS application in a certain way to meet a financial accounting need.
On the flip side, non-technical management tends to underestimate and undervalue technical expertise either by ego or by naïveté. One of my grandmothers used to wonder how I could “make any money by playing on the computer all day,” when what she saw as play was actually work. Not video games, mind you. She saw computers as a means to an end, in her case entertainment or socializing. Highly skilled clients of mine, like physicians, while curious, are often bewildered that there are sometimes technical or policy limitations that don’t match their expectations and make their request untenable.
When we talk about something like an LLM, it simply doesn’t possess the ability to reason, which is precisely what is needed for that kind of work.
> 2. Letting the Definition of Done Include Customer Approval
In the olden days we used to model user workflows. Task A requires to do that and that, we do this and this and transition to workflow B. Acceptance testing was integral step of development workflow and while it did include some persuasion and deception, actual user feedback was part of the process.
As much as scrum tries to position itself as delivering value to the customer, the actual practices of modeling the customer, writing imagined user stories for them and pulling acceptance criteria out of llama's ass ensures that actual business and development team interact as little as possible. Yes, this does allow reduce the number of implemented features by quite a bunch, however by turning the tables and fitting a problem inside the solution.
Think about it, it is totally common for website layouts to shift, element focus to jump around as the website is loading or more recently two step login pages that break password managers. No sane user would sign these off, but no actual user has participated in the development process, neither at design phase, nor at testing phase.
You know this future isn't happening anytime soon. Certainly not in the next 100 years. Until then, humans will be taking care of it and no one will want to work at a place working on some Fransketeinian codebase made via an LLM. And even when humans are only working on 5% of the codebase, that will likely be the most critical bit and will have the same problems regarding staff recruitment and retention.
We’re just going to see more and more issues like this as more and more software is used in applications like this. I would be willing to bet that a Tesla would also spontaneously crash if left on for hundreds of hours, but they just rarely if ever are left on that long.
Ford F150 Lightning had a similar issue on a cross country road race some YT'ers put on. It died at 13% battery, Ford said it was due to not letting the truck rest.
There never will be an adequate industry-wide certification. There is no universal “good enough” or “when to stop” for security. What constitutes “good enough” is entirely dependent on what you are protecting and who you are protecting it from, which changes from system to system and changes from day to day.
The budget that it takes to protect against a script kiddy is a tiny fraction of the budget it takes to protect from a professional hacker group, which is a fraction of what it takes to protect from nation state-funded trolls. You can correctly decide that your security is “good enough” one day, but all it takes is a single random news story or internet comment to put a target on your back from someone more powerful, and suddenly that “good enough” isn’t good enough anymore.
The Internet Archive might have been making the correct decision all this time to invest in things that further its mission rather than burning extra money on security, and it seems their security for a long time was “good enough”… until it wasn’t.
None of what you just said about US law is relevant here. Yes, Cloudflare has to abide by international law where it operates. This is established and every company across the globe is subject to it.
Cloudflare operates in and has a physical data center presence in Moldova, serves content owned by Moldovan citizens, and serves content to Moldovan citizens. Thus, they are subject to Moldova law. If they don’t want to be subject to it, they can remove their operations from the country and remove any interactions with Moldovans.
The site in question is presumably not hosted in Moldova, so the thing you're suggesting is unworkable. Suppose country A has common carriage laws that prohibit a provider from denying service without a court order and the thing being hosted in country A is legal in country A but not country B. If the provider removes it they're in violation of the laws of country A, where it's being hosted. If they can now be found in violation of the laws of country B, where it isn't being hosted but is illegal, that's a catch 22.
Moreover, it's pointless to expect that to do any good because the customer could obviously just use a provider that operates in country A but not in country B. Therefore, a presence in country B should be irrelevant when that isn't where the customer is because you're otherwise just setting up a catch 22 for no benefit.
> Then they have to withdraw from one of those countries.
This is equivalent to saying that no company can have operations is more than one country. Countries have so many laws that there will be a conflict between them somewhere.
The obvious and longstanding solution is for the company to set up a foreign subsidiary and then the subsidiary in that country complies with that country's laws. But that's not the same thing as expecting the subsidiaries in other countries to comply with the laws of a country they're not in.
What's "they"? The Cloudflare subsidiary in Moldova is presumably a different entity than the one in the US. The issue is they're trying to enforce the law of Moldova against the US corporation for things it does in the US.
If us-east-1 ever suffered a “FULL” data loss, it would be a company-ending event for so many companies that it would practically end society as we know it.
OVH’s failure was a single building. That’s the problem with a lot of server hosters - even Google has their availability zones all co-located in the same building, so a physical event like a fire could take down an entire region. AWS has AZs in physically separate locations, each with 1+ separate DCs.
Before Covid, no team had an RTO mandate, so ProServe wasn’t really special here. In ProServe you were still expected to be in an office regularly, but it was just understood that you wouldn’t be in an Amazon office all the time because you’re likely at a client’s office instead.
Post-covid, it’s mostly the same, although now even many clients aren’t requiring consultants to come in. But when they do, you’re expected to be there.
This undersells the fact that there’s a lot more to infrastructure management than “janitoring”. You and many others may want to just say “here’s my code, ship it”, but there’s also a massive market of people that _need_ the customization and deep control over things like load balancers, because they’re pumping petabytes of data through it and using a cloud-managed LB is leaving money and performance on the table. Or there are companies that _need_ the strong isolation between regions for legal and security reasons, even if it comes with added complexity.
A lot of developers get frustrated at AWS or Azure because they want to deploy their hobby app on it and realize it’s too difficult dealing with stuff like IAM - it’s like trying to dig a small hole in your garden and someone suggests you go buy a Caterpillar Excavator, when all you needed was a hand trowel. The reason this persists is because AWS doesn’t target the hobby developer - it targets the massive enterprise that does need the customization and power it provides, despite the complexity. There are, thankfully, other companies that have come in to serve up cloud hand trowels.
There is no “one size fits all” cloud. There probably never will be. They’re all going to coexist for the foreseeable future.
You’re completely off the mark here. I’ve worked at a Big4 company before on reports like this. These reports aren’t paid for by other companies at all. They’re internally funded and done by the internal research teams. The motivations behind them are numerous: marketing, having artifacts to help rank at the top of stuff like Gartner reports, and even because believe it or not the people that work there sometimes genuinely enjoy researching and publishing reports. Reports like this are the consulting company equivalent of a tech company’s engineering blog bragging about their new scalable infrastructure or whatever.
If you see a report published by a company that says “PwC did research for us”, then yes, it has likely been influenced by that company. But a report like this that is entirely PwC branded is not that.
I saw examples of both your and GP's experiences in my experience at a big4.
Unfortunately none I saw (sample size: a handful in detail and perhaps dozens to a skim) followed even basic statistical practices I had learned in undergraduate studies at a well-respected university.
There were clues that at least some of the parties involved knew better, but the imperative to publish completely overwhelmed any instinct for academic rigor.
It was dressed up as "eminence", which came after sold work and delivered work (in order) in annual reviews. Statistical rigor would probably help eminence, but there were faster paths to eminence.
Can we not do this? Everyone knows that “serverless” doesn’t actually mean there are no servers. It’s not productive to do this “haha gotcha!” trope every time someone uses the serverless term.
Serverless refers to the fact that you can launch individual workloads on the platform while abstracting away the underlying infrastructure. Yes, to set up dokku you still need to provision a server. But to deploy an application onto dokku after it’s been set up, you do that without worrying about provisioning new infra for your app. That’s what is “serverless” about it, and it’s a perfectly acceptable use of the term.
"Serverless" means 1- pay for what you use. 2- No infra setup, ever. Dokku requires a server that you have to manage. It is not serverless. You should never hit a scaling wall.
Azure Functions are serverless to us, but for the team developing and deploying that feature they are not serverless.
Dokku provides a tool so that once you deploy projects they can be ‘serverless’.
1- That would throw out serverless with (free) unlimited use (A la PocketHost)
2- Then getting a third party to set up Dokku and then using that would qualify
(Because it'd be the same as getting AWS to setup their server abstraction)
The platform is serverless, you hosting it probably not, maybe server-light, as you setup the abstraction and use that for many apps
> Can we not do this? Everyone knows that “serverless” doesn’t actually mean there are no servers.
Then maybe people shouldn't use a term that means "there are no servers". One doesn't get to complain if they use a word to mean something the opposite of its actual meaning, and then people don't like it.
The actual meaning of words is defined by how people use them. Serverless has a very specific, well-defined meaning despite its seemingly contradictory etymology.
Are you the sort of person that says "ackshewelly people in orbit aren't weightless" or complains that wireless headphones technically contain wires, or that motionless rocks are actually moving really fast because the Earth is moving through space...
A lot of the people that are hawking AI, especially in management, are chasing a future where there are no humans, because AI writes the code and maintains the code, no pesky expensive humans needed. And AI won’t object to things like bad code style or low quality code.