On Wed, Aug 28, 2019 at 11:12 AM Mark Randall <firstname.lastname@example.org> wrote:> On 28/08/2019 15:54, Chase Peeler wrote: > > Bottom line is that we live with the not-so-good stuff so that we can > focus > > on adding new great stuff. The not-so-good stuff isn't holding us back, > and > > trying to fix things like undeclared variables would have absolutely ZERO > > positive effect on our business, which uses this application every day. > > This is a classic case of technical debt. It might not bite you in the > ass today, tomorrow, or next week, but it will inevitably bite you in > the ass at some point, and the longer it's left, the more it's going to > hurt when that time comes. >Yes, it is. However, it's technical debt that is no longer growing. We make payments on it when we can, but, the majority of our limited resources are focused on building new things, we a careful focus on minimizing technical debt as much as possible (I don't think it's possible to totally avoid it).> Don't build your business on a foundation of eggshells and then complain > when something comes along that makes those eggshells crumble. > > I think our foundation is a bit stronger than that, but, I'll go with the analogy:All I'm asking is that we don't purposely try and break those eggshells if it isn't necessary. I'm also not the one that built it on the eggshells - I'm just the one that is now in charge of developing the system that someone else left sitting eggshells. I'm the one in charge of making sure our business (not a software company, by the way) that uses that system continues to grow, regardless of whether it's built on eggshells or diamonds.> -- > Mark Randall > > Just keep in mind that the harder the upgrade path is, the more peoplethere are that just won't do it. Whether they stick with an old version of PHP forever or switch to something else entirely. If the reason the upgrade path is so difficult is for something that the users don't even perceive as a benefit, it's even more likely to drive them away. Tell me how this benefits: 1) The user that already initializes their variables 2) The user that actually utilizes the fact that you don't have to initialize your variables. I would say it has no benefit to the first person, but, it doesn't hurt them either. It actually hurts the second person. The main benefits I see from this is that it will: 1.) help people that do want to initialize their variables find places where they forgot to do so. There are tons of tools, including most IDEs, which will also do this. 2.) Force new developers to conform to what some people view as a best practice 3.) Allow those that want to make PHP a more strict and less forgiving language to cram that down the throat of all of the users that don't want to see that.> -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >-- Chase Peeler email@example.com
Hello, as many later posters in the thread have said - a lot of notices, especially uninitialised variables, are classic technical debt. For example, I just recently fixed a bug, that did this: `$array['key'] += $cost` - the array key was not initialised. Well, turned out that in this case instead of null, it actually grabbed some garbage number out of memory and screwed up the calculations where the total was off by a few hundred euro. Previous dev did care about notices and/or warnings and god knows how long that issue was in production and how many calculations it affected before it was caught. There is also another side effect on performance. error handling in PHP is not free - it does take some significant amount of time. And the more warnings/notices like that you have, the bigger the impact. I have migrated an old code base that was riddled with notices - just fixing those improved performance by 100% without adjusting anything else. Single page load generated 3.5MB of notices and warnings. It also fixed quite a few bugs just because vars got their proper initial values. From time to time I get reminded when I go back into the crappy code how unpredictable it can be. And the point about PHP 's future. Planning should be done for at least the next 10 years and in today's environment, PHP needs a stricter mode that is just across the board. A project that I start today is by default in strict types mode, PHPStorm has 99.9% of inspections enabled, code analysers are configured and you will not be able to leave a potentially undefined variable in my codebase. git commit hook will just reject it. Frankly, today I do not care what PHP was 5 years ago and how people used it. I care what PHP is today and will be in 5 years when my app goes into production and is actively developed. I also dedicate resources in my budget to keep our software up to date and perform TLC on it. I just do not allow the business to ignore it. A lot of that TLC is done by just regular development workflow - you see crap, you take 5 minutes to fix it. A lot of the time executives don't even know we did the TLC, nor they even should - that's part of our daily responsibilities.
Hi!> For example, I just recently fixed a bug, that did this: `$array['key'] += > $cost` - the array key was not initialised. Well, turned out that in this > case instead of null, it actually grabbed some garbage number out of memoryThis would be a serious engine bug that you should submit to bugs.php.net (probably as security issue, because "garbage from memory" can contain sensitive data, and such bug could leak things like SSL private keys outside). This however should not be part of this discussion since this is engine bug, not expected behavior. -- Stas Malyshev firstname.lastname@example.org
On 28/08/2019 16:37, Chase Peeler wrote:> I'm also not the one that built it on the eggshells - I'm just the one that > is now in charge of developing the system that someone else left sitting > eggshells.That's a challenge which at some point or another will face all technical leads. You have to go to the people making the decisions and say: "Okay, look, we've got ourselves a problem here. We've dug ourselves into a hole by cutting corners, building up debt, and we've never made it a priority to fix it, and now it's causing us problems. It's not one person's fault, it's something that has collectively developed over time, but the reality is, the problem is there and needs fixing." And when the manager asks "What problems?" you say something like: "The language we use is moving towards a much stricter approach to handling ambiguous or error prone code. This can only be considered a good thing, but it is going to mean that a lot of our technical debt is going to manifest as errors that will stop our site from function..." Then the manager will go "Can't we just keep using the version we are on?" You reply: "We can for a short period, perhaps an extra year or two, but the reality is that PHP is moving forward, and the current version won't be supported forever, and even if it were, we would be missing out on major performance enhancements and new features that could help us to build new features". The manager says: "Lay this out to me" You reply: "It's like our company car still works, but it no longer tighter meets emissions standards so they won't let us take it into the city any more" "Crap", the boss replies "Okay, we had best fix that" -- Mark Randall