> On 28 Aug 2019, at 23:04, Chase Peeler <chasepee...@gmail.com> wrote:
>
> On Wed, Aug 28, 2019 at 11:37 AM Kalle Sommer Nielsen <ka...@php.net> wrote:
>
>> Hi
>>
>> Den ons. 28. aug. 2019 kl. 17.54 skrev Chase Peeler <chasepee...@gmail.com
>>> :
>>> You going to come and fix the issues? It's an internal application and
>>> most of those messages are coming from legacy areas of the code which are
>>> mainly "it works, so leave it alone" things. Instead of going back and
>>> spending time trying to fix those boondoggles, we invest the time of our
>>> developers (there are 2 others besides myself) into building new features
>>> that help our business grow. Time permitting, we try and update some of
>> the
>>> legacy areas, but, we usually find it's a better investment to just
>> rebuild
>>> them at that point.
>>>
>>> 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.
>> If
>>> I went to our executive team and said "Can we delay that new scheduling
>>> system that will really help our business so I can go back and update
>> code
>>> to get rid of these undeclared variable notices?" I'd get laughed at!
>>>
>>> Like I've said before - can we please stop pretending we understand
>>> everyone else's situation? Maybe my situation is unique. My gut tells me
>> it
>>> might be unique among people on this list, but, that it's actually pretty
>>> common among the myriad of developers out there which never get involved
>> in
>>> these discussions.
>>
>> I'm sorry, but like Mark Randall has already pointed out then this is
>> a classic example of technical depth. At one point you must choose,
>> "Do I want to upgrade to the latest version of PHP or do I want to fix
>> the issues which is caused by the technical depth in my stack?".
>
>
> I don't get to make that choice, though. The executives do.
>
I thought you said you were the tech lead? Part of building an application is
maintaining it.
And honestly, your claim about “it’s technical debt that is no longer growing”
is incorrect. Like financial debt, technical debt will accrue “interest” - in
this case, it’s going to prevent you from upgrading to a newer release of PHP.
Believe me I understand your situation, in terms of code very well. This RFC,
the short open tags one, and probably some more before 8.0 is frozen will all
affect an active client project I’m tech lead for.
In every case, I’m still for the change: because making the change means one
less type of sloppy-but-“working” code I’m going to see and have to task
someone to fix in the future.
If you can’t currently schedule some percentage of development time to
maintaining/fixing existing code, (you *did* say you’re the tech lead, right?)
this RFC makes your job easier then: you have an external control factor that
your executives (who apparently make technical decisions?) cannot argue
against, and cannot deny.
>
>> I get
>> it, writing new code is always more fun, it really is,
>
>
> It's not about what is more fun. It's about what is necessary for our
> company to grow, move forward, and survive. What good is fixing old code if
> our company withers away while we do it since we aren't supporting them
> with the new things the need to move forward? We aren't building things on
> top of that old code, so, the new things we build aren't accruing
> additional technical debt as a result of the existing technical debt.
>
Well presumably a working, secure application/website is necessary for the
company to just survive, let alone grow.
> I have
>> previously worked with companies with that same attitude that "we'll
>> fix it later", but at one point that becomes such a burden and if your
>> management doesn't believe in putting in resources to actual
>> maintenance of your infrastructure, then I'm sorry but it does not
>> sound like a healthy place to be (no offense meant).
>>
>> That's not exactly our attitude. If something is really broken, we fix it.
> We are not focusing our limited resources on updating things that currently
> work just because we don't like how they were built. Most of it was done
> 10-15 years ago, and, even if we had the resources to update it, we'd be
> better off just rebuilding it altogether. Let me focus on the technical
> debt that has high interest, instead of the debt that doesn't really impact
> anything, like undeclared variables.
Exactly how many instances of undeclared variables do you have? This talks
about PHP8, so its expected 7.4 due late November this year will be the last
version that doesn’t error on your code. 7.4 will have 2 years of full support
and a further year of security support. Can you *really* not find the time to
fix undeclared variables in the next 39 months?
>
>> Right now your argument is merely trying to hold back changes which
>> will bite that technical depth of yours, and everytime an argument has
>> been raised towards your concerns it has been met with "Will you come
>> and fix it?", "I demand that X, Y or Z tool is available for me to
>> use", etc., so again, I'm sorry but I'm not buying this argument.
>>
>> No, it's just that we should weigh the positives and the negatives. If we
> want to move PHP forward, we need to look at new features, and fixing old
> things that are really broken. I don't consider undeclared variables only
> generating a notice to be something that's "really broken." It still might
> be worth doing, though, if there isn't much of a reason not too. The
> current system doesn't prevent anyone from properly initializing their
> variables. Nothing prevents a company from doing code reviews or employing
> other tools to make sure their developers always initialize their
> variables. Why do we have to FORCE everyone else that wants to use PHP to
> do that as well?
>
> To me, what makes PHP great is its flexibility. Does that mean some people
> out there write some really bad code? Yes, it does. Heck, a lot of that
> code lives in our legacy code base and was probably written by me. But, the
> flexibility doesn't PREVENT anyone from writing truly great code, either.
> The only things that prevents great code are the great features we haven't
> implemented. Instead of focusing on those, it seems we spend our time
> trying to decide how we can take away some of the languages strengths. Even
> if you don't view it as a strength, is it really such a weakness that it's
> hurting the language?
Yes. Because people will write code that abuses it, and projects end up where
you are now: with ridiculous (in terms of the amount and also how simple it is
to fix) technical debt, arguing that PHP shouldn’t become objectively better,
because it’s going to break their apparently unmaintained application.
>
> Some things we can solve by an opt-in, like the strict_types declare,
>> however other things so fundamental to the language should not have
>> any options to alter its behavior, that should be consistent. We have
>> spend a long time trying to carve a migration path and advocate
>> against options which changes language behavior across installations.
>> If we continue down this path, then its just a runtime version of
>> php.ini with a million declare statements on top of each file, each
>> having multiple meanings and an added complexity to maintain the code,
>> not a burden I think userland developers need as it is.
>>
>> I agree. I don't think an opt-in is a great way to do it. That's why I
> think it just shouldn't be done. I just view an opt-in model as the least
> evil way to do it, if we do in fact have to do it.
>
>
>> --
>> regards,
>>
>> Kalle Sommer Nielsen
>> ka...@php.net
>>
>
>
> --
> Chase Peeler
> chasepee...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
