On Mon, Apr 10, 2023 at 6:42 PM Arvids Godjuks <arvids.godj...@gmail.com> wrote:
> > > On Tue, 11 Apr 2023 at 00:03, Deleu <deleu...@gmail.com> wrote: > >> >> >> On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks <arvids.godj...@gmail.com> >> wrote: >> >>> >>> >>> >>>> *snip to keep the email short* >>>> >>>> >>> Hello Deleu, I want to highlight your response specifically, because you >>> blame the wrong people here. >>> This is the failure of the business owner to plan accordingly and ignore >>> all the warnings for years and decades. That is if any developer raised any >>> concerns lately, which I also have seen quite a bit when "yes man" just >>> shove code into the meatgrinder for a year or two and then just move to the >>> next job: "It's not my problem, the next guy will deal with this". And that >>> feeds the vicious cycle, and the owner is either oblivious or does not >>> understand the implications because "well, it works, it generates money" at >>> the moment right until that plane hits the ground and things blow up. >>> I've handled a big legacy project, did major updates to it, seen how an >>> effort of 1 month of my time to drag it into the modern day paid off over >>> the next 6 months by picking up development speed by 3x with the same team >>> of 5 people + me. In 1 year we started to literally take away clients from >>> our competitors who could not keep up with us and we had a literal line of >>> clients to onboard, we had to scale our sales team 3x and had a backlog of >>> 6 months still. All stemmed from a single decision "I will tackle this, we >>> need it to update to newer PHP". Business owners were really stoked that >>> they actually listened to developers. >>> >>> You cannot expect to run code that was written 2 decades ago without >>> major updates on modern language versions. It's not possible for almost any >>> language that is being actively developed. Think laterally - instead of >>> hand-fixing every null check out there, introduce a library that can handle >>> data structures and handle the nulls for you en mass. Isolate the internals >>> and just pass already sanitized values into it. Suddenly you cut off like >>> 90% of the needed fixes that prevent you from running your code. It's still >>> needs fixing, but at least you give it good data to start with, so it does >>> not error out. >>> -- >>> >>> Arvīds Godjuks >>> +371 26 851 664 >>> arvids.godj...@gmail.com >>> Telegram: @psihius https://t.me/psihius >>> >> >> Thanks for your reply, I understand everything you mean here by improving >> a development flow. I've been responsible to for doing that improvement for >> the past 6 years and I'm pretty close to retiring 100% of the legacy code, >> but I still need a couple of years to do it. I have long ago convinced the >> people in my business that we need to pay this technical debt. >> >> You mentioned that I'm blaming the wrong people, but I'm not blaming >> anyone here. I have 4 teams working with me to replace our entire legacy, >> one bite at a time, but I lead only 1 of those teams. The other 3 teams >> have not only decided that the technical debt needs to be paid, but also >> its not worth it to pay it with PHP and have move to Typescript. >> >> My points are: >> >> - development practices has changed and we know it, but it takes time to >> shutdown legacy >> - we are actively working towards paying that technical debt and PHP >> improvements are great to help with it, but the deprecations aren't always. >> - like it or not, there is a community unhappy with how hard it has >> become to maintain a PHP codebase. >> >> I believe there's a lot more leeway in breaking BC and fast evolving the >> language around projects that have started in 2018+ with automation tests >> from day one. Introducing a BC break on PHP 8.3 about something that was >> first released on PHP 7.4 is orders of magnitude easier to deal with than >> BC breaks on things first Introduced on or before PHP 5.6. If we could just >> have a way to opt-in to a faster-paced language for all new code while not >> breaking PHP 5.6 features until the previous generation of software can be >> retired, that would be awesome. >> >>> > I do have to ask: How any of that is the concern of PHP the language, PHP > the project? This is pure and simple is a company issue. Now they have to > pay for their decision by probably buying some 3rd party extended support. > I think that's a very honest and on-point question. Which is somewhat related to what I meant to mention here: https://externals.io/message/119834#119846 but got called out as "spreading BS" by Larry here: https://externals.io/message/119834#119868 I don't agree with Larry and I think you're dead right. PHP has a limited resource and maybe it has decided that the "legacy community" is not a priority and/or not worth the work. If that's the decision, I have nothing else to argue and I can accept it. -- Marco Deleu
