Most non-tech businesses have no budget for that kind of tech debt work.
That's fine. I'm sure there are some that also don't have a budget for fire insurance, or a security system, or whatever. For anybody who wants to gamble with no fire insurance, or not fixing tech debt, that's a conscious choice they get to make. Now they have to be responsible for the outcome(s) of their choices.
Using python2 is in no way similar to going without fire insurance. There are internal-only apps that will run fine for decades to come with no risk to the business on py27.
There are many maintenance mode projects where the switch to 3 represents absolutely no upside and is all downside risk. Not everyone is developing web apps in constant flux that are exposed to the Internet. That is a tiny fraction of python’s use cases.
> I'm sure there are some that also don't have a budget for fire insurance, or a security system, or whatever. For anybody who wants to gamble with no fire insurance, or not fixing tech debt, that's a conscious choice they get to make.
A security system and fire insurance is at most around $2000/month, and it's a cost that is understood and often required by law. Diverting a $100k+/year employees to spend their time on tech debt is quite a bit more expensive.
Companies rightly try to minimize time devoted to tech debt.
Actually most of them do money, however in these type of companies tech people aren't listed to as much,as maybe sales or finance are. It just depends on who's running the circus on the day: if it's a guy with short term goals only- you'll never get a budget,but the ones with longer visios would most likely listen.
There's not budgeting for fire insurance or security systems, and then there's deliberately building your workplace next door to an asylum for pyromaniacs and across the street from a gas station.
If you built software using Python 2 at any point in the past 5 years, you have no right to complain about the added technical debt of updating to Python 3. But not wanting to incur that technical debt in the first place would also have been a good reason not to use Python 2 in the first place; whether that means adopting Python 3 early or simply using a completely different language.
"Hey Joe, why did our customer database get leaked and published on a dark-net site?"
"Hey boss, we're using an outdated programming language for which security updates are no longer provided, because we were told there's no budget for fixing technical debt."
"Congratulations, you're fired."
Same outcome either way... might as well make some effort to do the right thing along the way...
You’re confusing runtimes with the language. Py27 as a language has no security flaws that would allow a database to get leaked.
People will continue to use py27 going forward with likely a pay-for-support runtime because that’s cheaper and less risky than changing a million lines of python code.
Nah, you're not fired. That's why you CYA and get it in writing. It's the manager who decided that they didn't want to do a rewrite, it's not your problem they didn't listen to your advice.
Like it or not, there are a lot of teams that choose to incur technical debt to avoid what is seen as needless work on something that is working fine at the moment.
You're missing the point. If decision makers saw it coming that Python will just break in two, they would have never allowed its use. Other "serious" programming languages rarely if ever break, and when they do, it's usually minor.
Python2 will almost certainly still remain in widespread use and it will still get security updates through alternative distribution channels. It's not that much work fixing such relatively rare issues versus migrating a major codebase.
It's not "broken"... Python3 is just the evolution of the language. Languages change and evolve, some more and some less than others. Sure, Java or COBOL maybe have done a better job of not breaking backwards compatibility, but Python 3 isn't exactly Perl 6 here.
But hey, if some 3rd party group effectively forks the language and maintains a Python2 branch after the official EOL date, good on them. But I'd argue that using that is risky in the same way that using a Pale Moon or Waterfox is (arguably) riskier than using mainstream Firefox.
> It's not "broken"... Python3 is just the evolution of the language.
Python3 broke compatibility for spurious reasons. The language didn't change that much, it could have kept compatibility with minor concessions.
> Java or COBOL maybe have done a better job of not breaking backwards compatibility...
Literally every single other major language has done a better job at it. That's a big part of why they are major languages. Also, most of these are statically typed, so any minor breaking change is far less risky to pull off.
> ...but Python 3 isn't exactly Perl 6 here.
Well, maybe if Perl6 didn't happen Perl wouldn't be irrelevant today.
What are you talking about? C++ has had very few breaking changes in the language.
If you're talking about ABI breaking, that's a different story. Python breaks the ABI in every major release as well. That generally requires a recompile, not a major code migration.
That's fine. I'm sure there are some that also don't have a budget for fire insurance, or a security system, or whatever. For anybody who wants to gamble with no fire insurance, or not fixing tech debt, that's a conscious choice they get to make. Now they have to be responsible for the outcome(s) of their choices.