It’s literally no different than how to clean up old projects over the last 30 years of software engineering

I don’t understand why all this stuff is all of a sudden “new.”

It feels like we’ve got an entire generation of people who never had to spend their time factoring or doing hard infrastructure work

It’s actually pretty baffling how rare it is to find somebody who has consistent experience in refactoring that is under the age of 40

▲

hilariously 6 hours ago | parent | next [-]

That's because the businesses got into the habit of new C level means new project, obviously the old code is bad.

I even had a PE buy the company I worked at, put in a new CEO, and his goal was to rewrite the entire code base in a year. I asked him what problems this would solve and never got a straight answer besides "its yucky" and "people told me they dont like it."

I have had multiple upper management teams decide that "dealing with this product is too hard, let's start from scratch" as if the new thing wouldn't have the same problems of the old thing, but with less effort put into it.

People love to work on new, all the possibilities and none of the bugs!(yet)

▲

AMerrit 5 hours ago | parent | next [-]

Yep, I worked at a small company that got bought by a bigger one. We had a solid if aging product to support which was one of the big players for the niche. Once there was a leadership change, 2/3 of the devs got put on building a replacement software. Then in a couple of years our subgroup got spun off and sold to PE and the v2 project was shelved for another brand new design to align with the new ownership. I left just before the spin-off, but witnessed how the original software slowly rotted away and all of the marketshare dominance we had for that area slipped away.

Devs love new tech and the product people love something new to put their stamp on, but chasing that high can be ruinous.

	▲	AndrewKemendo 5 hours ago \| parent [-]
		I think that’s actually the product incentive structure inside Google iirc

▲

AndrewKemendo 5 hours ago | parent | prev [-]

I think that’s right

I have seen over the past decades this concept of just reusable throw it away code becomes the norm and that’s why also I’m always surprised to look at people complaining about AI development and it’s like yeah it’s just the same as all other development at this point everything‘s just frameworks and throwaway code

I’m not even mad at it but it’s just one of those things where people are like “I’ve never dealt with anything like this”

But it’s the majority of operational software engineering since more or less forever

	▲	hilariously 5 hours ago \| parent [-]
		I think its also the pyramid of age - as you work in this field a lot of people burn out, the field was significantly smaller in the past and has shown huge growth, and the young say "yes sir!" and work nights and weekends on the fucking stupid idea while the older folks push back. So in general most of the people have worked on a bunch of greenfield development, thought of the project 2 years old as aged out entirely, and never thought you might "maintain" something at all.

▲

penultimatename 5 hours ago | parent | prev | next [-]

In my experience, this is because a modern engineering organization is laser focused on delivering value. Value rarely aligns with refactoring an existing, working implementation. If need the data, you build an integration on the output data. If something isn’t working well enough, you fix that one thing, you don’t refactor half the application.

Getting product to prioritize refactoring a working product is like pulling teeth. Even if maintenance is a moderate drain on resources, work beyond maintenance on working solutions isn’t seen as a net win.

▲

sumeno 2 hours ago | parent | prev | next [-]

It's different because LLMs can generate code that immediately needs to be refactored at speeds that were unfeasible before. There was a practical limit on the amount of technical debt that could be created in a day before, now that limit is 10x or 100x higher. It can be generated far faster than it can be fixed.

▲

AndrewKemendo 2 hours ago | parent [-]

Then code factoring was never the key problem was it?

It was organizational discipline

Again this is the same problem previously…organizational lack of discipline means you get some diva to build some un maintainable thing and then you have to go back and refactor it later

The problem is the same the speed is different I acknowledge but both our organizational problems and have nothing to do with writing code or technical

▲

sumeno 2 hours ago | parent [-]

If a neighbor leaves their dog's poop in my yard I have a problem. If someone builds an industrial scale dog poop delivery mechanism that delivers tons of dog poop to my yard every day I have a different problem even though the underlying basics are the same.

	▲	AndrewKemendo 14 minutes ago \| parent [-]
		I think we’re in agreement The problem moves from situation to structure

▲

andwur 5 hours ago | parent | prev | next [-]

The problem in isolation isn't new as such, but I think there's a combination of new factors to differentiate it:

1) the speed at which AI-generated codebases grow is far in excess of what human developers can achieve. What took years to accumulate in the past can be produced in a few days/weeks.

2) past large codebases that end up in a similar state would often see a mixture of developer talent. So while you might have a few developers who produce dross, there will also be a few who can pull it back together. You start to see threads of sanity appear, and from that the potential to refactor further, rather than the uniform spaghetti monster that's near unassailable from every direction that we're now getting from the pure-AI projects.

3) external perception differs. AI has been pitched, sadly by sales, influencers and shills rather than experts in the field, to business leaders as the solution to all development problems. When you present this issue to stakeholders you're then immediately put on the defensive, e.g. it's initially viewed as negativity for the sake of negativity. With past technical debt discussions, outside of a few key parties (too often the person responsible for overseeing said debt developing), I've found that it's relatively straight forward to explain technical debt, the need to refactor and maintain systems as a going concern. For the technically disinclined it's easy to draw parallels with building maintenance: you don't expect to build an office and then never spend another cent, it takes continued investment and maintenance to keep it safe, clean, functional and compliant. The difficulty again with the AI projects here I think comes back to the accelerated timeline, as you're inevitably going to be saying months after it's created that it probably needs to be burnt to the ground in lieu of the far greater task of refactoring it. As opposed to a legacy project that has been going for years or decades, where it's a far more palatable concept to take drastic action.

▲

kaydub 3 hours ago | parent | prev | next [-]

You're just witnessing "Software Developers" cry out over LLMs.

"Software Engineers" are embracing LLMs and getting shit done same as before.

▲

kgwgk 5 hours ago | parent | prev [-]

> how to clean up old projects

What’s “new” is indeed the “new” bit in cleaning up new projects.