Sounds good, but unless it advocates for HR practices that retain talent, and corporate practices that incentivize Quality, it probably won't result in any changes.
Personal Quality Coding practices have been around for as long as software has been a thing. Way back when, Watts Humphrey, Steve McConnell, and Steve Maguire wrote books on how to maximize personal Quality. Many of their techniques still hold true, today.
But as long as there are bad people managers and short-sighted execs, you'll have shit quality; regardless of who does the work.
burnt-resistor · 7h ago
I'm disillusioned because it never happens, but purveyors of conferences and books are happy to sell the promised land™ of how "it's really going to be different this time."
Processes, tools, and diligence vigilantly seem the most apparent path. Perhaps rehash the 50 year old debate of professionalization while AI vibes coding is barking at the door, because what could possibly go wrong with even less experience doing the same thing and expecting a different result.
rachofsunshine · 1h ago
It doesn't happen because building the best software is not the goal of a software engineering job.
If you want to do that on your own time, that's fine - but the purpose of a job is economic. Of course you should write software of some reasonable quality, but optimizations have diminishing economic returns. Eventually, the returns are lower than the cost (in time, money, etc) of further optimizing, and this break-even point is usually at a lower level of quality than engineers would like it to be. Leadership and engineering managers know this and behave accordingly.
astrobe_ · 54m ago
Companies can sacrifice every thing for "time to market" - optimization, maintainability, security and safety even - but underestimate the costs of doing that. It is actually more a marketing choice than an economic choice.
One can be skeptical about the implied statement and leadership/management knows what it is doing beyond delivering at the (arbitrarily) set time. One definition of Quality is to satisfy a need entirely at the lowest cost in the shortest time, but more often that not, the last term gets 90% of the attention.
wiseowise · 3m ago
> but underestimate the costs of doing that
Do they? I’ve been fighting against the tide for years until I understood that all of quality this and quality that doesn’t matter. Sure, it sucks to be on the receiving end of buggy software, but this where you vote with your money. At work? Finish the task with least amount of resources and move on.
jcgrillo · 1h ago
While I agree with everything you've said, I think you might be making an assumption that quality costs time. In my experience this isn't the case, unless you're starting from a low quality codebase or working with low quality people. A high quality team can produce high quality software in less time than it takes a low quality team to produce low quality software meeting the same functional requirements.
The whole ballgame is making sure you have no low quality people on your team.
wiseowise · 1m ago
> A high quality team can produce high quality software in less time than it takes a low quality team to produce low quality software meeting the same functional requirements.
Key word is ‘can’. And it takes far more time and money to assemble “quality” team.
jasode · 34m ago
>A high quality team can produce high quality software in less time than it takes a low quality team to produce low quality software meeting
Your scenario may be true in some cases but in general, more quality in software will cost more time & effort & money. If you isolate the experimental variable of studying "quality" to a particular single dev team, that team will require more time & effort to produce higher quality. The main contributor to higher quality and reliability is tests.
E.g. SQLite is considered "high quality and bulletproof". A big reason is SQLite's test code is ~590x more LOC than the core database engine: https://www.sqlite.org/testing.html
If someone finds a rare bug, the SQLite team adds it to the tests to prevent future regressions.
Same situation with NASA's higher standards of software quality for space missions. Famous article includes descriptions of the extensive tests they do: https://archive.is/HX7n4
Tests like unit tests, fuzz tests, Red Team adversarial tests, chaos monkey failure tests, etc... all require extra engineering time. Most companies don't want to pay the extra costs or extend the timelines to include all those tests.
pydry · 1h ago
This is only true in certain contexts. Most of the time quality is looked over not because it genuinely isnt important but simply because it's hard to perceive.
Ive watched many businesses appreciate the benefits of software quality (happy customers, few incidents, fast delivery) without ascribing it to software quality.
Then, when it went away, they chalked up the disasters to something else as well, throwing fixes at it which didnt work.
At no point in time did they accurately perceive what they had or what they lost, even at the point of bankruptcy.
Part of the problem is that the absence of bugs, incidents and delays just feels normal. Part of the problem is that second order effects are hard to detect.
Conversely, because it's so hard to see I think it can make a good competitive moat.
intelVISA · 3h ago
Aye, it never happens but it does sell a lot of books ;)
I don't think we'll reach this promised land™ until incentives re-align. Treating software as an assembly line was obviously The Wrong Thing judging by the results - problem is how can we ever move to a model that rewards quality perhaps similar to (book) authors and royalties?
Owner-operator SaaS is about as close as you can get but limits you to web and web-adjacent.
ozim · 3h ago
Just like all the fitness content.
Get couple shredded guys and gals to show off how fit they are so everyone feels guilty they are snacking past 8PM.
Sell another batch of “how to do pushups” followed by “how to do pushups vol.2” with “pushup pro this time even better”.
Where in the end normal people are not getting paid for getting shredded, they get paid for doing their stuff.
I just constantly feel like I am not a proper dev because I mostly skip unit tests - but on the other hand I built last 15 years couple of systems that worked and were bringing in value.
qznc · 2h ago
You could switch into a domain where safety-critical software is developed. Here devs complain about the inverse problem: Why are we required to have 100% test coverage?!
(The answer btw: Because nobody would be able to explain to a jury/judge that 80% or whatever is enough)
zoover2020 · 2h ago
Why would you skip unit tests? Especially in the AI age. You can quickly verify your behavior. Also, by not writing them you're also missing out on opportunities to modularize your code.
Obviously, this assumes you write enterprise grade code. YMMV
ozim · 1h ago
You can write modular code without writing tests - I write testable code - I don't write tests. When I need I can always add them back, but I tend to skip it as mostly it doesn't make sense.
But still cottage industry of "clean code" is pushing me into self doubts and shame.
jackblemming · 3h ago
It happens when an ex-engineer is in a leadership position. The results are good, but it’s typically a small part of having a successful company.
However, you should want to build quality software because building quality things is fulfilling. Unfortunately certain systems have made the worship of money the end all be all of human experience.
supportengineer · 5h ago
I’ve seen one company in my 30 year career with effective quality control.
The QE engineers and the development engineers were in entirely separate branches of the org chart. They had different incentive structures. The interface documentation was the source of truth.
The release cadence was slow. QE had absolute authority to stop a release. QE wrote more code than development engineers did with their tests and test automation.
popularonion · 9m ago
Every company I’ve seen that maintains a separate QA org chart, inevitably offshores the entire QA org to India or China, with predictable results.
In 2025 I think the only thing that makes sense is having SDETs embedded in development teams.
thecupisblue · 2h ago
I've worked at one of those companies where software quality was paramount.
They did TDD for a long time, they wrote Clean Code™, they organised meetups, sponsored and went to conferences, they paid 8th Light consultants to come teach (this was actually worth it!) and sent people to Agile workshops and certificates.
At first, I was like "wow, I am in heaven".
About a year later, I noticed so much repetition and waste of time in the processes.
Code was at a point where we had a "usecase" that calls a "repository" that fetches a list of "ItemNetworkResponse" which then gets mapped into "Item" using "ItemNetworkResponseToItemMapper" and tests were written for every possible thing and path.
They had enterprise clients, were charging them nicely, paying developers nicely and pocketed extra money due to "safety buffers" added by both engineers, managers and sales people, basically doubling the length of any project for "safety".
The company kept to their "high dev standards" which meant spending way more time, and thus costing way more, than generic cookie-cutter agencies would cost for the same project.
This was great until every client wanted to save money.
The company shut down last year.
wolvesechoes · 4m ago
From your description it looks like that company wasn't into quality but into chasing every fad of software industry.
MoreQARespect · 33m ago
It sounds like they were cargo culting ThoughtWorks.
ThoughtWorks and companies like them do work but theyre heavily reliant upon heavy duty sales. Delivery at high quality is necessary but not sufficient.
tsimionescu · 4h ago
The company I work for used to be organized like this a decade or so ago, and people who were around back then still tell horror stories that we all laugh about. Things like bug targets not being met leading to extreme bug ping-pong ("you didn't specify the phase of the moon when this crash on clicking Run reproduced, Needs Information", "this GUI control is misaligned, here are 5 bugs, one for each button that is not where it should be", endless hostile discussions on the severity of bugs and so on).
Sofwtare development and quality assurance should be tightly integrated and should work together on ensuring a good product. Passing builds over a wall of documentation is a recipe for disasters, not good quality software.
djaychela · 5h ago
Was the end result better or worse for this? I'm not being facetious, I just can't get if you think it was a good idea!
GoblinSlayer · 2h ago
> The interface documentation was the source of truth.
lol, fire business analysts and let tech writers do their job. Sounds like some kind of VC black company.
It seems to be socially associated with the Handmade Hero and Jon Blow Jai crowd, which is not so much concerned that their software might be buggy as that it might be lame. They're more concerned about user experience and efficiency than they are about correctness.
swesour · 9h ago
> which is not so much concerned that their software might be buggy as that it might be lame
This is not at _all_ my interpretation of Casey and JBlow's views. How did you arrive at this conclusion?
> They're more concerned about user experience and efficiency than they are about correctness.
They're definitely very concerned about efficiency, but user experience? Are you referring to DevX? They definitely don't prize any kind of UX above correctness.
tsimionescu · 4h ago
From what I've seen, they are very much in a game developer mindset: you want to make a finished product for a specific use, you want that product to be very well received for your users, and you want it to run really fast on their hardware. When you're done with it, your next product will likely be 80% new code, so long term maintainabity is not a major concern.
And stability is important, but not critical - and the main way they want to achieve it is that errors should be very obvious so that they can be caught easily in manual testing. So C++ style UB is not great, since you may not always catch it, but crashing on reading a null pointer is great, since you'll easily see it during testing. Also, performance concerns trump correctness - paying a performance cost to get some safety (e.g. using array bounds access enforcement) is lazy design, why would you write out of bounds accesses in the first place?
mustache_kimono · 7h ago
> This is not at _all_ my interpretation of Casey and JBlow's views.
IMHO this group's canonical lament was expressed by Mike Acton in his "Data-Oriented Design and C++" talk, where he asks: "...Then why does it take Word 2 seconds to start up?!"[0]. See also Muratori's bug reports which seem similar[1].
I think it is important to note, as the parent comment alludes, that these performance problems are real problems, but they are usually not correctness problems (for the counterpoint, see certain real time systems). To listen to Blow, who is actually developing a new programming language, it seems his issue with C++ is mostly about how it slows down his development speed, that is -- C++ compilers aren't fast enough, not the "correctness" of his software [2].
Blow has framed these same performance problems as problems in software "quality", but this term seems share the same misunderstanding as "correctness". And therefore seems to me like another equivocation.
Software quality, to me, is dependent on the domain. Blow, et. al, never discuss this fact. Their argument is more like -- what if all programmers were like John Carmack and Michael Abrash? Instead of recognizing software is an economic activity and certain marginal performance gains are often left on the table, because most programmers can't be John Carmack and Michael Abrash all the time.
> Their argument is more like -- what if all programmers were like John Carmack and Michael Abrash? Instead of recognizing software is an economic activity and certain marginal performance gains are often left on the table, because most programmers can't be John Carmack and Michael Abrash all the time.
At least for Casey his case is less that everyone should be Carmack or Abrash but that programmers often through their poor design choices prematurely pessimise their code when they don’t need too.
kragen · 8h ago
By reading their blog posts and watching their videos.
alabhyajindal · 46m ago
I hate talk titles of this form: "Most of your projects are stupid. Please make some actual games.". So annoying. I know it's not personal but I'm sure a better title exists for all talks that choose this form. Why do you have to insult the audience?
kilpikaarna · 5h ago
This thing feels pretty weird to me. I'm guessing it's an attempt at organizing some sort of european Handmade event, and trying to keep it small.
But between the sparse website, invite-only and anonymous organizers, it just feels like it's emphasizing the reactionary vibes around the Handmade/casey/jblow sphere. Like they don't want a bunch of blue-haired antifa web developers to show up and ruin everything.
Glad to see they got Sweden's own Eskil Steenberg though. Tuning in for that at least.
userbinator · 3h ago
Like they don't want a bunch of blue-haired antifa web developers to show up and ruin everything.
There's a reason web developers, and the ecosystem/community around them, are the butt of many jokes. I don't think it's at all surprising that the injection of identity politics into the software industry has had a negative effect on quality.
loktarogar · 2h ago
> I don't think it's at all surprising that the injection of identity politics into the software industry has had a negative effect on quality.
That's a pretty broad claim. This conference could be in response to a perceived negative effect on quality, but claiming that as a fact seems hard to back up to me
pydry · 22m ago
Ive noticed that some of these types tend to be well meaning young people (often girls) who are super excited to have scored a job doing developer outreach for $BIGTECH.
It's a clever political tactic coz a 50 year old white male middle manager at Microsoft trying to become a board member on an open source foundation would face a lot more hostility than a 20-something girl who pushes all of the diversity buttons.
It mirrors the rather successful marketing strategies for a string of movies including Ghostbusters movie and Barbie, among others. i.e. "There's a certain kind of person who doesnt like our latest corporate offering...". Who wants to be that person?
kristoff_it · 4h ago
That's pretty much what it is, it's a reaction to an implosion that happened last year in the Handmade Network related to the Handmade Seattle conference which caused the conference organizer and the community leads to go separate ways.
> Like they don't want a bunch of blue-haired antifa web developers to show up and ruin everything
You write this like this is a bad thing.
I just came to a conference to learn some cool new tech, but instead got lectured about my transphobia, that my database is systemic discrimination and my HDD being named „slave“ means I burn crosses in my free time, even though I have zero family relations to anything America.
I mean this screams fun right from the get go.
imwally · 8h ago
You would think a conference that advocates for quality software would have a better website.
mrbluecoat · 6h ago
I hesitated mentioning it, thinking perhaps I was the only one who thought so. The twitch video failing to load, the static text on blurred background text video, the horizontal text scrolling on mobile, ...
GoblinSlayer · 1h ago
Text in video always sucks, but that's just how twitch coding sessions work.
reactordev · 12h ago
Curious how they’ll balance the business needs of moving fast with AI vs quality because my agents aren’t that good. While it works, I’m often having to cleanup afterwards - slowing everything down. I was almost as fast when I had just basic intellisense.
Anyway, I’ll watch the twitch stream from across the pond.
bradly · 10h ago
In DJB's paper on software quality he identifies actionable strategies for code quality and code security that were born out of frustration to sendmail's exploit after exploit. Very accessible and fun read: https://cr.yp.to/qmail/qmailsec-20071101.pdf
I would expect this conf to expand on those types of concepts and strategies.
lotyrin · 12h ago
They probably just manage to realize that being seen to be "moving fast with AI" simply isn't a goal unto itself, that it has to deliver something of value beyond itself.
prisenco · 10h ago
We could be in a tortoise vs. hare situation... Unless we find ourselves back in the conditions of the 2010's again, thoughtfully building software to be high quality and high performance may win out in the long run over "move fast and break things."
lotyrin · 9h ago
Always have been. It’s why the vast majority of disposable corporate garbageware, products chasing a buck, consumer shovelware, etc is built on the shoulders of thoughtfully designed, high quality, mature software that stands the test of time. No popular production software runs on an OS kernel someone vibe coded yesterday. Durable utility is where quality lies, as the cost of quality is able to amortize. Chasing trends is, by definition, costly.
Terr_ · 12h ago
Or at least "value" beyond that reaped by current investors unloading their shares onto "Greater Fool" buyers at high prices.
Suppafly · 9h ago
>Curious how they’ll balance the business needs of moving fast with AI vs quality
Why would they need to do that? Is that even a goal or something that this conference is addressing at all?
ktallett · 11h ago
There are plenty of alternative software needs that do not need to be AI based nor do they need to change tactics due to the current obsession with AI.
ants_everywhere · 10h ago
> Curious how they’ll balance the business needs of moving fast with AI vs quality because my agents aren’t that good
I would guess the same way humans do.
Put brain in creative mode, bang out something that works
Put brain in rules compliance mode and tidy everything up.
Then send for code review.
switchbak · 11h ago
Well, a couple years ago this stuff all sucked (well, a lot more). Yeah it's in many cases somewhat borderline now, but still - this is frickin magic compared to what I thought was possible just a little while ago.
My question is how far does it go - are the gains going to peter out, or does it keep going or even accelerate? Seems like one of the latter two thus far.
xyzzy123 · 11h ago
Yeah it's interesting, unless I lean hard on them, AI coding agents will tend to solve problems with a lot of "hedging" by splitting into cases or duplicating code. It is totally fine with infinity special cases and unless you push for it, they will solve most problems with special cases and not generalise or consolidate (gemini, claude code at least both seem to have this behaviour).
I feel like this comes about because it's the optimal strategy for doing robust one-shot "point fixes", but it comes at the cost of long-term codebase heath.
I have noticed this bias towards lots of duplication eventually creates a kind of "ai code soup" that you can only really "fix" or keep working on with AI from that point out.
With the right guidance and hints you can get it to refactor and generalise - and it does it well - but the default style definitely trends to "slop" in my experience so far.
zahlman · 10h ago
To be fair, a lot of humans also have this problem.
rkagerer · 12h ago
Where can you actually learn the substance of what this conference is about?
All I found is a Twitch tagline that reads "Software is getting worse. We're here to make it better."
Suppafly · 9h ago
The have a list of the presentations in the original link. That should at least give you some idea what they're going to talk about.
__grob · 3h ago
I know Berkeley Mono when I see it! My go-to terminal font for coming up on three years. Automatically gets me pumped about this conference.
fzeindl · 4h ago
What is needed is more evidence based software engineering. Statistical methods applied to datasets correlating issue trackers with code ASTs to show us exactly which ways of coding are correlated with longer issue times, frequent bugs etc.
I sometimes wonder if there could be an optimal number of microservices. As far as I know no one has connected issue data to the number of microservices before. Maybe there‘s an optimal number like „8“ which leads to lower number of bugs and faster resolution times.
aaronbasssett · 1h ago
They don't advocate for diversity that's for sure
tsss · 1h ago
Good for them.
wavemode · 12h ago
The programming language in the background of this website appears to be Odin.
jeberle · 9h ago
Bill Hall "Ginger Bill", the creator Odin, is a speaker on day 1.
jofzar · 6h ago
> A software conference that advocates for quality
I am going to keep saying this, if your main tagline/ethos is broken by your website you have failed.
* On mobile the topics are hidden without scroll over. You also can't read multiple of the topics without scrolling right as you read.
* The background is very distracting and disrupts readability.
* None of your speakers have links to their socials/what they are known for.
* > Who are the organizers?
Sam, Sander and Charlie.
* * Ah yes, my favourite people.... At least hyperlink their socials.
brabel · 4h ago
It bothers me that this is from Sweden, a most inclusive country, while being pretentiously exclusive. I live in Sweden and wouldn’t mind going to a small conference on my holidays, but unfortunately I can’t find the “charming town” where this is supposedly taking place nor know how to find Sam, Sander and Charlie.
gjadi · 2h ago
> Physical attendance will be invite-only. Tickets will not be publicly available. Invitees will receive an attendee guide with further information.
ravenstine · 11h ago
If only they could get Jonathan Blow to be a speaker.
zx8080 · 9h ago
For a non-engineer (business) person the case "engineering quality vs move fast break things" sounds more like "slow & expensive VS fast". The choice is obvious.
no_wizard · 8h ago
It’s not that at all though, the adage “slow down to speed up” applies, because high quality engineering will inevitably increase throughput in the long run.
Really that’s the core of it
bGl2YW5j · 7h ago
You should challenge this idea in your internal monologue. Learn a bit more about technology and how it's made. "Fast" in most cases most definitely does not equal cheap, especially over the long term.
hackable_sand · 7h ago
It's more like "slow and expensive vs. fast and more expensive"
userbinator · 6h ago
"How can you not have enough time to do it right, but enough time to do it twice?"
gjadi · 2h ago
> plan to throw one away; you will, anyhow.
rewgs · 4h ago
What a fantastic way of responding to/framing this.
bravesoul2 · 5h ago
> Where in Sweden is it happening?
> In a charming small town
satisfice · 2h ago
There is no indication I see from the website that anything about this conference relates to quality, specifically.
I don't see how anyone can be "for" quality and not talk about how quality can be assessed. Where are the talks about that?
WeirderScience · 12h ago
Looking forward to Casey Muratori's talk!
prisenco · 10h ago
When I saw the title of the conference I immediately thought of him so I'm not surprised he's headlining!
throwawaymaths · 11h ago
the logo is an unsettling convolution of the back orifice logo
ravenstine · 11h ago
Now that you mention it, I'll never see the symbol of the Galactic Empire the same way again.
ta988 · 7h ago
That's once again a really diverse panel of speakers... /s
No comments yet
xyst · 10h ago
Seems like a waste of time to me, especially in this age of AI slop somehow passing as quality. Just another excuse to drink/network/party on company’s dime.
However, I would be interested in establishing a union for technologists across the nation. Drive quality from the bottom up, form local chapters, collectively bargain.
cushychicken · 3h ago
I think I’ve finally figured out just what is that annoys me about the “software quality” crowd.
Quality is a measurement. That’s how it works in hardware land, anyway. Product defects - and, crucially, their associated cost to the company - are quantified
Quality is not some abstract, feel good concept like “developer experience”. It’s a real, hard number of how much money the company loses to product defects.
Almost every professional software developer I’ve ever met is completely and vehemently opposed to any part of their workflow being quantified. It’s dismissed as “micromanagement” and “bean counting”.
Bruh. You can’t talk about quality with any seriousness while simultaneously refusing metrics. Those two points are antithetical to one another.
vodou · 2h ago
Some thoughts regarding this:
1. It is partly because the typical metrics used for software development in big corporations (e.g., test coverage, cyclomatic complexity, etc) are such a snake oil. They are constantly misused and/or misinterpreted by management and because of that cause developers a lot of frustration.
2. Some developers see their craft as a form of art, or at least an activity for "expressing themselves" in an almost literary way. You can laugh at this, but I think it is a very humane way of thinking. We want to feel a deeper meaning and purpose in what we do. Antirez of redis fame have expressed something like this. [0]
3. Many of these programmers are working with games and graphics and they have a very distinct metric: FPS.
I notice you have not quantified any aspect of your opinion, here. Which is not surprising, since your opinion is unrelated to facts, science, experience, or wisdom.
Quality is not a "real, hard number" because such a thing would depend entirely on how you collect the data, what you count as data, and how you interpret the data. All of this is brimming with controversy, as you might know if you had read more than zero books about qualitative research, epistemology, the philosophy, history, or practice of science. I say "might" because of course, the number of books one reads is no measure of wisdom. It is one indicator of an interest to learn, though.
It would be nice if you had learned, in your years on Earth, that you can't talk about quality with any seriousness while simultaneously refusing to accept that quality is about people, relationships, and feelings. It's about risks and interpretations of risk.
Now, here is the part where I agree with you: quality is assessed, not measured. But that assessment is based on evidence, and one kind of evidence is stuff that can be usefully measured.
While there is no such thing as a "qualitometer," we should not be automatically opposed to measuring things that may help us and not hurt us.
Personal Quality Coding practices have been around for as long as software has been a thing. Way back when, Watts Humphrey, Steve McConnell, and Steve Maguire wrote books on how to maximize personal Quality. Many of their techniques still hold true, today.
But as long as there are bad people managers and short-sighted execs, you'll have shit quality; regardless of who does the work.
Processes, tools, and diligence vigilantly seem the most apparent path. Perhaps rehash the 50 year old debate of professionalization while AI vibes coding is barking at the door, because what could possibly go wrong with even less experience doing the same thing and expecting a different result.
If you want to do that on your own time, that's fine - but the purpose of a job is economic. Of course you should write software of some reasonable quality, but optimizations have diminishing economic returns. Eventually, the returns are lower than the cost (in time, money, etc) of further optimizing, and this break-even point is usually at a lower level of quality than engineers would like it to be. Leadership and engineering managers know this and behave accordingly.
One can be skeptical about the implied statement and leadership/management knows what it is doing beyond delivering at the (arbitrarily) set time. One definition of Quality is to satisfy a need entirely at the lowest cost in the shortest time, but more often that not, the last term gets 90% of the attention.
Do they? I’ve been fighting against the tide for years until I understood that all of quality this and quality that doesn’t matter. Sure, it sucks to be on the receiving end of buggy software, but this where you vote with your money. At work? Finish the task with least amount of resources and move on.
The whole ballgame is making sure you have no low quality people on your team.
Key word is ‘can’. And it takes far more time and money to assemble “quality” team.
Your scenario may be true in some cases but in general, more quality in software will cost more time & effort & money. If you isolate the experimental variable of studying "quality" to a particular single dev team, that team will require more time & effort to produce higher quality. The main contributor to higher quality and reliability is tests.
E.g. SQLite is considered "high quality and bulletproof". A big reason is SQLite's test code is ~590x more LOC than the core database engine: https://www.sqlite.org/testing.html
If someone finds a rare bug, the SQLite team adds it to the tests to prevent future regressions.
Same situation with NASA's higher standards of software quality for space missions. Famous article includes descriptions of the extensive tests they do: https://archive.is/HX7n4
Tests like unit tests, fuzz tests, Red Team adversarial tests, chaos monkey failure tests, etc... all require extra engineering time. Most companies don't want to pay the extra costs or extend the timelines to include all those tests.
Ive watched many businesses appreciate the benefits of software quality (happy customers, few incidents, fast delivery) without ascribing it to software quality.
Then, when it went away, they chalked up the disasters to something else as well, throwing fixes at it which didnt work.
At no point in time did they accurately perceive what they had or what they lost, even at the point of bankruptcy.
Part of the problem is that the absence of bugs, incidents and delays just feels normal. Part of the problem is that second order effects are hard to detect.
Conversely, because it's so hard to see I think it can make a good competitive moat.
I don't think we'll reach this promised land™ until incentives re-align. Treating software as an assembly line was obviously The Wrong Thing judging by the results - problem is how can we ever move to a model that rewards quality perhaps similar to (book) authors and royalties?
Owner-operator SaaS is about as close as you can get but limits you to web and web-adjacent.
Get couple shredded guys and gals to show off how fit they are so everyone feels guilty they are snacking past 8PM.
Sell another batch of “how to do pushups” followed by “how to do pushups vol.2” with “pushup pro this time even better”.
Where in the end normal people are not getting paid for getting shredded, they get paid for doing their stuff.
I just constantly feel like I am not a proper dev because I mostly skip unit tests - but on the other hand I built last 15 years couple of systems that worked and were bringing in value.
(The answer btw: Because nobody would be able to explain to a jury/judge that 80% or whatever is enough)
Obviously, this assumes you write enterprise grade code. YMMV
But still cottage industry of "clean code" is pushing me into self doubts and shame.
However, you should want to build quality software because building quality things is fulfilling. Unfortunately certain systems have made the worship of money the end all be all of human experience.
The QE engineers and the development engineers were in entirely separate branches of the org chart. They had different incentive structures. The interface documentation was the source of truth.
The release cadence was slow. QE had absolute authority to stop a release. QE wrote more code than development engineers did with their tests and test automation.
In 2025 I think the only thing that makes sense is having SDETs embedded in development teams.
They did TDD for a long time, they wrote Clean Code™, they organised meetups, sponsored and went to conferences, they paid 8th Light consultants to come teach (this was actually worth it!) and sent people to Agile workshops and certificates.
At first, I was like "wow, I am in heaven".
About a year later, I noticed so much repetition and waste of time in the processes.
Code was at a point where we had a "usecase" that calls a "repository" that fetches a list of "ItemNetworkResponse" which then gets mapped into "Item" using "ItemNetworkResponseToItemMapper" and tests were written for every possible thing and path.
They had enterprise clients, were charging them nicely, paying developers nicely and pocketed extra money due to "safety buffers" added by both engineers, managers and sales people, basically doubling the length of any project for "safety".
The company kept to their "high dev standards" which meant spending way more time, and thus costing way more, than generic cookie-cutter agencies would cost for the same project.
This was great until every client wanted to save money.
The company shut down last year.
ThoughtWorks and companies like them do work but theyre heavily reliant upon heavy duty sales. Delivery at high quality is necessary but not sufficient.
Sofwtare development and quality assurance should be tightly integrated and should work together on ensuring a good product. Passing builds over a wall of documentation is a recipe for disasters, not good quality software.
lol, fire business analysts and let tech writers do their job. Sounds like some kind of VC black company.
It seems to be socially associated with the Handmade Hero and Jon Blow Jai crowd, which is not so much concerned that their software might be buggy as that it might be lame. They're more concerned about user experience and efficiency than they are about correctness.
This is not at _all_ my interpretation of Casey and JBlow's views. How did you arrive at this conclusion?
> They're more concerned about user experience and efficiency than they are about correctness.
They're definitely very concerned about efficiency, but user experience? Are you referring to DevX? They definitely don't prize any kind of UX above correctness.
And stability is important, but not critical - and the main way they want to achieve it is that errors should be very obvious so that they can be caught easily in manual testing. So C++ style UB is not great, since you may not always catch it, but crashing on reading a null pointer is great, since you'll easily see it during testing. Also, performance concerns trump correctness - paying a performance cost to get some safety (e.g. using array bounds access enforcement) is lazy design, why would you write out of bounds accesses in the first place?
IMHO this group's canonical lament was expressed by Mike Acton in his "Data-Oriented Design and C++" talk, where he asks: "...Then why does it take Word 2 seconds to start up?!"[0]. See also Muratori's bug reports which seem similar[1].
I think it is important to note, as the parent comment alludes, that these performance problems are real problems, but they are usually not correctness problems (for the counterpoint, see certain real time systems). To listen to Blow, who is actually developing a new programming language, it seems his issue with C++ is mostly about how it slows down his development speed, that is -- C++ compilers aren't fast enough, not the "correctness" of his software [2].
Blow has framed these same performance problems as problems in software "quality", but this term seems share the same misunderstanding as "correctness". And therefore seems to me like another equivocation.
Software quality, to me, is dependent on the domain. Blow, et. al, never discuss this fact. Their argument is more like -- what if all programmers were like John Carmack and Michael Abrash? Instead of recognizing software is an economic activity and certain marginal performance gains are often left on the table, because most programmers can't be John Carmack and Michael Abrash all the time.
[0]: https://www.youtube.com/watch?v=rX0ItVEVjHc [1]: https://github.com/microsoft/terminal/issues/10362 [2]: https://www.youtube.com/watch?v=ZkdpLSXUXHY
At least for Casey his case is less that everyone should be Carmack or Abrash but that programmers often through their poor design choices prematurely pessimise their code when they don’t need too.
But between the sparse website, invite-only and anonymous organizers, it just feels like it's emphasizing the reactionary vibes around the Handmade/casey/jblow sphere. Like they don't want a bunch of blue-haired antifa web developers to show up and ruin everything.
Glad to see they got Sweden's own Eskil Steenberg though. Tuning in for that at least.
There's a reason web developers, and the ecosystem/community around them, are the butt of many jokes. I don't think it's at all surprising that the injection of identity politics into the software industry has had a negative effect on quality.
That's a pretty broad claim. This conference could be in response to a perceived negative effect on quality, but claiming that as a fact seems hard to back up to me
It's a clever political tactic coz a 50 year old white male middle manager at Microsoft trying to become a board member on an open source foundation would face a lot more hostility than a 20-something girl who pushes all of the diversity buttons.
It mirrors the rather successful marketing strategies for a string of movies including Ghostbusters movie and Barbie, among others. i.e. "There's a certain kind of person who doesnt like our latest corporate offering...". Who wants to be that person?
https://handmade.network/blog/p/8989-separating_from_handmad...
https://handmadecities.com/news/splitting-from-handmade-netw...
You write this like this is a bad thing.
I just came to a conference to learn some cool new tech, but instead got lectured about my transphobia, that my database is systemic discrimination and my HDD being named „slave“ means I burn crosses in my free time, even though I have zero family relations to anything America.
I mean this screams fun right from the get go.
Anyway, I’ll watch the twitch stream from across the pond.
I would expect this conf to expand on those types of concepts and strategies.
Why would they need to do that? Is that even a goal or something that this conference is addressing at all?
I would guess the same way humans do.
Put brain in creative mode, bang out something that works
Put brain in rules compliance mode and tidy everything up.
Then send for code review.
My question is how far does it go - are the gains going to peter out, or does it keep going or even accelerate? Seems like one of the latter two thus far.
I feel like this comes about because it's the optimal strategy for doing robust one-shot "point fixes", but it comes at the cost of long-term codebase heath.
I have noticed this bias towards lots of duplication eventually creates a kind of "ai code soup" that you can only really "fix" or keep working on with AI from that point out.
With the right guidance and hints you can get it to refactor and generalise - and it does it well - but the default style definitely trends to "slop" in my experience so far.
All I found is a Twitch tagline that reads "Software is getting worse. We're here to make it better."
I sometimes wonder if there could be an optimal number of microservices. As far as I know no one has connected issue data to the number of microservices before. Maybe there‘s an optimal number like „8“ which leads to lower number of bugs and faster resolution times.
I am going to keep saying this, if your main tagline/ethos is broken by your website you have failed.
* On mobile the topics are hidden without scroll over. You also can't read multiple of the topics without scrolling right as you read.
* The background is very distracting and disrupts readability.
* None of your speakers have links to their socials/what they are known for.
* > Who are the organizers? Sam, Sander and Charlie.
* * Ah yes, my favourite people.... At least hyperlink their socials.
Really that’s the core of it
> In a charming small town
I don't see how anyone can be "for" quality and not talk about how quality can be assessed. Where are the talks about that?
No comments yet
However, I would be interested in establishing a union for technologists across the nation. Drive quality from the bottom up, form local chapters, collectively bargain.
Quality is a measurement. That’s how it works in hardware land, anyway. Product defects - and, crucially, their associated cost to the company - are quantified
Quality is not some abstract, feel good concept like “developer experience”. It’s a real, hard number of how much money the company loses to product defects.
Almost every professional software developer I’ve ever met is completely and vehemently opposed to any part of their workflow being quantified. It’s dismissed as “micromanagement” and “bean counting”.
Bruh. You can’t talk about quality with any seriousness while simultaneously refusing metrics. Those two points are antithetical to one another.
1. It is partly because the typical metrics used for software development in big corporations (e.g., test coverage, cyclomatic complexity, etc) are such a snake oil. They are constantly misused and/or misinterpreted by management and because of that cause developers a lot of frustration.
2. Some developers see their craft as a form of art, or at least an activity for "expressing themselves" in an almost literary way. You can laugh at this, but I think it is a very humane way of thinking. We want to feel a deeper meaning and purpose in what we do. Antirez of redis fame have expressed something like this. [0]
3. Many of these programmers are working with games and graphics and they have a very distinct metric: FPS.
[0] https://blog.brachiosoft.com/en/posts/redis/
Quality is not a "real, hard number" because such a thing would depend entirely on how you collect the data, what you count as data, and how you interpret the data. All of this is brimming with controversy, as you might know if you had read more than zero books about qualitative research, epistemology, the philosophy, history, or practice of science. I say "might" because of course, the number of books one reads is no measure of wisdom. It is one indicator of an interest to learn, though.
It would be nice if you had learned, in your years on Earth, that you can't talk about quality with any seriousness while simultaneously refusing to accept that quality is about people, relationships, and feelings. It's about risks and interpretations of risk.
Now, here is the part where I agree with you: quality is assessed, not measured. But that assessment is based on evidence, and one kind of evidence is stuff that can be usefully measured.
While there is no such thing as a "qualitometer," we should not be automatically opposed to measuring things that may help us and not hurt us.