This is not just a software problem. I see it everywhere. Folks in business roles just as much as any other role. There is a surface-level operating framework to get a job done but the why/how is sometimes lost.
I always come back to an example in my past. Somehow automated a report. From Excel to Power BI. Then for months Power BI was wrong. Automation (more code involved for sure) made it run faster but then people forgot about the how - how to check/validate/etc. And since it was code - for many non technical people the whole thing was a lot harder to deal with needing to deep investigate issues.
For everything else the general mode is "can we make it work well enough". And when it breaks, well, we will curse and pry it open and either fix or rebuild it. There are many stories of a particular thing that was built long time ago by folks who are long gone and no one knows how it works or even where it physically is.
And it works fine; usually better than ensuring complete reliability from the get-go, when it is not clear if it is a long-term core feature or a kludge that will be obsolete soon. My 2c.
But I feel like it's a minority that really know how the software they're writing really works. And it's 10x worse for older legacy software.
Mostly because the people doing it don't care. Not judging, just reporting I guess. I know because I used to work in quite a few companies where the "money maker" app was on maintenance for years and nobody was able to answer questions or didn't even know most corners of it still existed.
This desperation mindset also often correlates with people writing code without care for the next maintainer.
And the scary part is that this also correlates with advocacy for going all-AI.
I don’t know anything about formal verification myself! But proof? I am sure we have seen that AI capabilities exceed humans on that front.
I recently started using Claude to write an app. I was going to write it by hand but was having trouble getting motivated, and I knew I had to "up my game" in the vibecodery anyway. So far it's been a lot of back and forth, I keep the leash pretty short because I don't want The Claude AI you see everywhere now.
But even with good intentions and the short leash, I find myself saying "yeah, whatever, it looks like it did what I told it to do" and not actually reading all the code. Some yes, all no. And this is for my own project, nobody is my boss here, and it's nothing I couldn't have done by myself.
Now imagine the incentives for someone who's doing it for money, whose boss is pushing them to do more AI and not less, who probably doesn't actually know how to do all the things the AI is doing for them, who looks around and sees who's getting promoted and who's getting laid off...
And remember that most of us, most of the time, no matter how much we might love computers and software, are that person.
But hey, it could be worse! Have you heard about the Literacy Crisis?
I used to think this but have come around to the opposite. I'm already seeing client projects where they went off and LLMd their way forward. A few hundred KLOC and many rounds of bug fix whack-a-mole later, they have something that's a giant house of cards.
Sure, once in this state the LLMs can repair issues at a faster rate than the humans can, but the damage is already done at that point. And it requires a lot of combined human/agentic effort to unfuck it.
That stops working once the code reach a certain size/complexity limit. It is a different limit for different people, but there is a point where there is just too many parts to be possible to fit in a head. There is also a middle stage where everything fits, but can't be accessed all at once but require some time to retrieve specifics when looking at areas not in recent memory. The middle step is more achievable the easier the code is to reason about by black boxing parts.
Yes, but it's not ever too much code for a team to understand, or a community. The question is whether you can build a team or community with enough trust and integrity that two things are always true:
1. Alice understands the fluxtron renoberator module she wrote.
2. Bob can also shift his attention there and understand it if necessary, because Alice writes clean code that was reviewed by John and Sally.
You can have Alice, Bob, John and Sally all be robots, and you can decide to trust the robots, but (so far anyway) it's a choice, not an inevitability.
Every large project I ever worked on worked exactly this way. What do you mean it was rare?
I'm ready to bet that is untrue. Sure, no one can recite the code, but people can quickly scan the module and refresh their memory as well as understanding the new changes, even after a while. If not, collaboration would have been impossible.
> Because 3 months later, the fluxtron renoberator module has been modified, fixed and refactored by 5 other people and looks little like Alice remembers it
I don't know for which type of projects those things happen, but good design can have a long staying power. Drastic refactoring in a short period is a clear sign of bad engineering.
> and Bob, well, he could never shift attention and actually understand it, nor could anyone else, because that's just a nice story we told ourselves that never worked in practice.
A lot of OpenSource projects are decades old, and while some core maintainers can stay for the lifetime of the project, new contributors came, understood the code, made changes, then left. Same for hires in companies.
I don't understand this part. When I was doing freelance consulting, my job was quite often "come to our office, scan this 40 million lines codebase and fix stuff for the next week". It was never a problem to read and get up to speed completely unknown codebases if you have basic programming ability. Much harder to do something that fits floaty business objectives though.