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.
P.S. I wish all the luck to the teams going with TypeScript rewrite. Having dealt with NodeJS on a sizeable project - never again (the npm ecosystem has an atrocious problem with code quality and bugs that are not fixed for decades - you have to raw dog it on low-level nodejs drivers and modules to get code that works reliably). I sincerely hope they know what they got themselves into, considering they were working on a PHP project. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
