It's easier to find bugs, fix them, yet there's less will than ever. My bosses just want speed and will give me a 30 minute lecture on why I don't need to solve a bug that Claude solved in 5 minutes, I've verified, and it's already in an open PR. All the while we're pushing out bugs faster and faster.
No matter how good AI gets at fixing bugs we'll never fix them when there's no will to fix things. Software will never be good if there's no will to make good software. The problem has always been about will. To many better products. It's insane that in a time where we can do better on speed and quality we still choose speed and tell ourselves it's velocity
It is not "will" it always is money.
There was an article some days ago where someone was claiming "with AI only you decide how many bugs you have" — well no the same forces apply because tokens are not free and business wants to do stuff that directly earns money.
Well we have to make cases and measure where the bug costs money and how. Lots of bugs are irrelevant and not blocking people from using the software. If bug doesn't drop database but is "dropdown doesn't exactly align" or "given precodnitions A,B and C something bad will happen" while A, B and C have very small possibility of occuring.
So it isn't money. You can argue that it is power, that the money is the proxy, but this still wouldn't answer the question.
The reason I'm pushing back hard here is these simplistic answers are just thought terminating cliches. They dismiss the problem, calling it inevitable and unsolvable. It only helps to preserve the status quo. It only helps empower those who seek to take our own. So I call bullshit
I spent about a decade coding, then half a decade in QA. QA has always been a thorn in everyone's side. The amount of money some companies spend on these departments just to ignore them is wild.
Now we've got an ability to push code out faster than ever, and absolutely zero innovation for QA. You simply cannot trust AI to verify your code is working. You can't have Quality Assurance without some form of assurance. So you're either hiring twice as many QA guys for the 10x output, or you're mostly ignoring the idea.
Economics has bubbles. Does computer science? Anyways, screw this. I'm moving to nursing.
Unfortunately, in many smaller companies, QA is no longer even a separate entity. It is foisted upon developers (and sometimes PMs.) It went the way of agile, similar to sysadmins and DBAs.
Something that might come out of all of this is that companies that previously slow rolled security fixes will now be forced to fix them quickly, because the speed of AI and the liability of being insecure.
USA has that digital misuse law that makes it a crime to use software in unintended ways. So claude or codex finding bugs in their software is actually illegal... I am not sure if really no one tried this yet or if they did and I just missed the news.
Yea, when their cyber insurance policies start biting them because AI found a bug months ago and it was never fixed I figure we'll start seeing a change.
With that said there are numerous companies that are very concerned about the situation. They know AI is finding bugs in their software at an accelerated rate, one they are having difficult times keeping up with because they want human understanding and review of the fixes to avoid introducing new bugs.
Did CrowdStrike actually suffer? That was a huge outage and their stock is today at an all time high. Seems like no one actually cares. Neither the companies providing the software, the companies purchasing the software, nor the markets.
To me, this is the craziest part about all of it. Why doesn't anyone seem to care?
Because the purpose of Crowdstrike is not to prevent exploits or make computing safer, its purpose is to allow corporate CTOs to tick a checkbox.
Why would they suffer? They showcased that they were big enough to disrupt the global economy. Why _wouldn't_ you invest in something so big and powerful?
This is the same as when junkies specifically seek batches of drugs on which others overdosed.
I know you're being sarcastic but what worries me is it seems people really do think that way. AI didn't create the addiction, but it's like switching from opium to fentanyl
Depends on the jurisdiction. Where I live, companies are not liable for insecure software, if sold to a private person for example. Enter huge botnets of crappy home routers. Hopefully this is going to change.
The better outcome would be for everyone to slow roll everything rather than speeding up the rate of bug propagation.
I guess I often don't know how good I have it as the owner of my own tech company. We've been busy fixing bugs and tackling tech debt, and I couldn't be happier.
Most places I've worked have been infuriatingly uninterested in fixing bugs, and would release software with major known bugs and a vague plan to fix them later. Of course, when "later" came, there were more features to cram. No time to fix those bugs.
I'm hoping one of the unintended side effect of it being essentially free to find and exploit (and fix) software bugs is that companies become less cavalier about shipping bugs in their software. Unlike most of the industry I don't believe "bugs are inevitable." Bugs are a choice developers make when they're rushing and careless and when all of their incentives are to ship quickly. You can ship bug-free software but it takes (or used to take) a really long time and a lot of care, care that commercial software developers just don't ever seem to muster.
Maybe when their software is getting 0wned over and over and 30 security issues are published a day, they'll start caring and taking their time.
Bugs are a choice by managers, not developers.
You probably never had developers working for you. First, if you don’t give them a deadline they will work on it for months trying to get it perfect, but it will still be buggy and do the wrong thing unless you keep very close attention. Second, because you must give deadlines due to the previous point, the result will be buggier still, as they will spend most of their times on what to name variables and how to structure the packages and modules. Their testing will cover their mocks and when put together in the real thing most functionality will just not work at all. I’ve seen this happen even with senior developers. With juniors it’s guaranteed to happen without a very good tutor. Take some fucking responsibility. If you deliver software, make sure it’s in a working state. Don’t blame your manager for everything, they did not force you to write shitty code, if you think they can do that you are not ready to work as a professional developer, you are just a code monkey.
I disagree, a bit. There should always be some contention between manager and developer. It's healthy. But I think many developers just remain silent and are afraid to speak up. They are afraid of losing their jobs, or worse, getting kicked out of the country. It's reasonable, but it is one of many factors that contribute to the negative feedback loop of myopic management.
We've all seen developers who game the system. They hide the bugs just enough so checked out management doesn't see them. They convince themselves that those bugs don't matter, even when they trip over them later. They get rewarded because they appear to move fast, eventually become management, and the whole thing gets worse as time goes on.
It's a structural problem. Yes, the level of influence is higher the higher up in the org chart you go, but there is still "power" at every level. Even the most junior developer has power. The worst thing we can do is become apathetic, shrugging it off, saying "well what can we do?" That attitude is one of many factors that got us to this point. Importantly, it is a factor we actually can influence.
That's why I object to it. Not because I think it is going to solve the problem overnight, but because it is a thing we have some power over. And it is a very different situation when one engineer in a team is vocalizing "our software has issues" while most of the team silently agrees vs several members of the team simply vocalizing agreement. There's no magic single variable fix to problems like these, but we got here because a bunch of little problems added up. Unfortunately, or fortunately, the way to solve it is through solving a bunch of little problems. Each seems insignificant in isolation, but they accumulate
My take is that when the bubble bursts good software will remain. Right now all the big players are hiding the cost. Anthropic (in my mind) is especially egregious at tokenmaxxing without telling you whats going on. A simple request to edit a text file launches multiple agents which takes ages, and burns tokens. All the while it calles it "Sautéeing" or whatever random verb they spew out as you wait for your answer.
> All the while it calles it "Sautéeing" or whatever random verb they spew out as you wait for your answer.
Today, while bitterly staring at Claude per my current employer's "use genAI or else" mandate, I got "bloviating."
My boss is a big yapper too
Very low signal information, preemptively trying to cover every rebuttal despite nobody ever planning on making one, in the few times someone does he plays devils advocate endlessly
Like bro just let us babysit these agents, everything’s going to happen
If your boss asks for X feature and you split it into 4 PRs, 3 that implement X and a 4th that fixes a security bug, how would they know? Someone that uses those 30mins like that isn't reviewing your PRs themselves. Just fix it and be done with it. You only needed to argue with the boss when you needed to make time for it which would delay something else. If it just appears done they'll just react with clap emoji later when you announced you also fixed this extra thing.
You haven't worked at conservative software shops I guess. The last place I worked at had this huge song and dance with you trying to raise a PR that looked irrelevant to the task at hand would lead to meeting with your lead dev, your manager and your skip level as you tried to explain why the bug needs fixing...
The worst one was where I fixed a datetime bug and although it had been sending out false alerts, I was asked to dry run the 5 lines of code I changed, like a coding interview. In all this pressure I forgot what the code was meant to do, and was dismissed and asked to set up another meeting with an explanation of all the various cases that could happen...
But, isn’t it our job to impress upon the managers the importance, in a certain regard?
Alternatively, what about just doing the right thing? Either you convince them to take this stuff seriously or you find alternate employment. How can you subject yourself to the moral degradation and conflict of principles? I could understand for someone with no other financial options, or in some sort of oppressive culture/economy. But most in our field probably don’t fall into those
Our job is to engineer. Our job is to build (good) products. Information can't just flow top down, it has to go the other way too.
What seems weird to me is that during "the good times" in our field, that happened more frequently. A strong employee market (as opposed to an /employeer/ market) seemed to be good for employee, employeer, and the people buying everything. But myopia is quick to set in.
That's the main motivation of why I speak up. There are consequences to our actions. Our choices may have small or little influence, but unfortunately the problem is that the world is complicated. The problems we face are mainly composed of many small issues that add up. I am surprised this is more contentious in places like HN as we deal with this every day. The way we solve big problems is we break them down into many different small and manageable problems. The only difference here is that we're viewing things bottom up rather than explicitly breaking them down. Though that is harder to figure out which small problems add up to the big problem. But we deal with this type of problem solving in programming all the time too.If you haven't heard it before, allow me to introduce you to Pournelle's Iron Law of Bureaucracy[0]. I think one of the important things it states is that the second group is actually bad for business. I think there's a common misconception. People are often saying "well it is good for business", pointing to all kinds of messed up shit. I don't buy that. It is myopically good for business, but not in any meaningful length of time. Though then again, as Buffet says "The market can stay irrational longer than you can stay solvent." Michael Burry famous learned this first hand.
[0] https://www.jerrypournelle.com/reports/jerryp/iron.html
Michael Burry managed just fine, I believe. Secondly, I think the "in every case" is too strongly worded. I am working in an org right now where it has not happened yet. Perhaps it is only a matter of time, but let me have my optimism.
Let's spend $5m to have a meeting about why we can't spend $50.
Penny wise, pound foolish
The best is the explanations are in the PRs. They even have Claude these days to answer their questions... I swear, these people are more addicted to spending money than they are about making money.
holy shit that sounds like a nightmar-ish work environment
That's mostly how I'm shifting to doing things but let's admit, this is metric hacking. And let's also admit, it takes longer to go through that song and dance than it actually takes to do the work.
You will see, they will change both laws and expectations, to say its normal for software to always have terrible bugs. You can always solve a problem by lowering your expectations. :-)
No laws are needed. We already have oligopolies. Don't like the buggy software? Go to the only other competitor who also has buggy software.
FFS, we're living in a world where Linux has more than doubled in popularity mainly due to Microsoft actively fleecing their customers. It's crazy
/I use arch btw (and have been on it for over a decade)
What law says software may not have bugs?!
Not explicitly laws, but like contracts, regulatory requirements, SLAs all indirectly enforce that
Well, they at least say that one is obligated to address bugs in a timely manner (where "not widely exploitable; won't fix" is a perfectly valid resolution).
!!! You described my experience in the workforce to a t! So frustrating that tech managers look at tech debt as a thing to be maintained at a certain level instead of allowing us to achieve perfection
Look, I'll defend high quality code all day long. Good code allows you to move fast just like taking 30s to tie your shoe laces allows you to run faster.
But we can't write high quality if we pretend that perfection exists. Globally optional solutions are the exception, not the norm. There's almost always tradeoffs we need to make. The high quality code, the high quality engineering, is understating, tracking, triaging, and minimizing those tradeoffs. It is writing code that allows you to change those decisions as quick and effectively as possible. But perfection doesn't exist. It's a good thing to chase, like Utopia, but ultimately unobtainable. A good engineer knows how to triage.
Advocating for perfect code will be a losing battle. But we should not, even for a second, let that be interpreted as meaning quality doesn't matter. I'm still frustrated with people who say "don't let perfection be the enemy of good enough" as most of the people that say that believe "good enough" is "it looks like it is working" and call a "demo" a MVP
Your tech manager is likely very aware of the imperfections and is making prioritizations and compromises to keep you employed.
Nah, I quit at the end of 2023, so much for those compromises
I have pride in my work, and having to watch it be destroyed repeatedly is not a way to keep me around.
That's exactly what managers should be doing.
Perfection is the enemy of progress. There will always be a balancing act.
Well, that goes with the metaphor. Debt is not an intrinsically bad thing, and most people agree on that: countries run deficits, people get mortgages and millionaires trade on leverage.
> instead of allowing us to achieve perfection
Huh?