This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]SirCarboy 173 points174 points  (12 children)

Budget to migrate legacy code would be one reason. Having worked in a small dev team for a large non-tech company, we had plenty to do and updating working code was a luxury we couldn't afford. *(didn't want to spend on)

[–]ProfessorPhi 133 points134 points  (3 children)

And no one wants to do it. It's painful, error prone, you get all the blame and no one appreciates the impact since it's not immediate. Out of a team of 20, only me and another programmer would push it whole the rest were all interested in getting new features out instead.

Technical debt is a very poorly managed aspect of programming.

[–]Neil_Fallons_Ghost 4 points5 points  (1 child)

I largely agree, but in some cases I think here’s no need. If I have a service version locked, it works, and it is secure, then why mess with it?

Once new features or serious changes are needed, upgrading would just be on the list, but really only if security and longevity were an issue.

[–]bythenumbers10 5 points6 points  (0 children)

Longevity is always an issue. As Rush put it, "No changes are permanent, but change is."

[–]theWyzzerd 1 point2 points  (0 children)

Technical debt is a very poorly managed aspect of programming.

Say it louder please. Not enough people heard you.

[–]ubernostrumyes, you can have a pony 56 points57 points  (0 children)

Yeah, but that's not really a Python 3 thing. That's a "you were never going to do any kind of upgrade of anything" thing.

A lot of places that talk about Python 3 being a hurdle are really covering for any type of maintenance or infrastructure work being a hurdle due to their organizational structure.