[NNagain] public service website slowness

[Steve Crocker]

Time: Many years ago
Place: Living room
Actors: My grandfather, my father, me

My grandfather, observing that I was about to turn 16, generously offered
to provide funds to buy me a used car.
My father quickly interceded.  "Not so fast."  "What about gas,
maintenance, etc?"
The discussion continued, reaching a decision that I should take a
part time job.

======================================

Why not address this problem head on?  Do not present plans to Congress for
upgrades, new capabilities, etc. unless the plan includes
appropriate funding for maintenance and upgrades.

Steve

SceneLiving room discussion

On Mon, Aug 19, 2024 at 10:41 AM David Bray, PhD via Nnagain <
nnagain at lists.bufferbloat.net> wrote:

> Part of the challenge is that several government websites usually only
> have a budget allocated to launch them - and then they collect dust (the
> O&M long-tail). So the lament is that a website that was made 18-25 years
> ago is slow to load nowadays (keeping in mind that client-side javascript
> wasn't really an option back then either).
>
> A much bigger problem is making sure legislators when they appropriate
> funds for a project that is intended to continue for multiple decades -
> those appropriators need to also include in that budget continuous
> refreshes to both the web UI/UX as well as the security posture. That's the
> other side of the issue, when legacy technology isn't funded IT security
> postures get progressively worse as sites get more and more out of date.
>
> Meanwhile we also need to encourage ways for continuous updates to both
> the UI/UX and the security to be done that aren't captured by incumbents
> who use this knowledge of the ins and outs of both the technology systems
> and associated human systems to charge inflated prices to keep things
> updated too?
>
> ... and this isn't only for government organizations.
>
> Ask Delta about their IT infrastructure and how when Crowdstrike/Microsoft
> Cloud hiccupped, how that created a ripple effect for them and their UI/UX
> too. O&M tied to legacy IT does have substantial impacts.
>
>
>
> On Mon, Aug 19, 2024 at 12:03 AM Dick Roy via Nnagain <
> nnagain at lists.bufferbloat.net> wrote:
>
>> Speed is not the problem … it’s how information to be transmitted is
>> encoded and more importantly, how much redundant info is being sent.  It’s
>> the MS mindset … give me a faster processor and more memory and I’ll give
>> you more bloated code to fill it up! When you put kindergarteners in
>> charge, you get a kindergarten solution! JJJ
>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> *From:* Nnagain [mailto:nnagain-bounces at lists.bufferbloat.net] *On
>> Behalf Of *Dave Taht via Nnagain
>> *Sent:* Sunday, August 18, 2024 7:03 PM
>> *To:* Network Neutrality is back! Let´s make the technical aspects heard
>> this time!; bloat
>> *Cc:* Dave Taht
>> *Subject:* [NNagain] public service website slowness
>>
>>
>>
>> This was a damning analysis of many government websites' speed.
>>
>>
>>
>> https://infrequently.org/2024/08/object-lesson/#the-golden-wait
>>
>>
>>
>>
>> --
>>
>>
>>
>> Dave Täht CSO, LibreQos
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>>
> _______________________________________________
> Nnagain mailing list
> Nnagain at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>


-- 
Sent by a Verified
[image: Sent by a Verified sender]
<https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y>
sender
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/nnagain/attachments/20240819/6c744899/attachment-0001.html>