Do you have any multi-year case studies of a real world, revenue generating application that successfully shows this? In my experience, software is never done, features are always added, never removed, which typically means "more script". This is a game of cost mitigation.
-
-
Replying to @chadhietala @slightlylate
Correct. Which is why loaded script needs to be O(features used) instead of O(features built). Route based code splitting is still the latter. Manual code splitting doesn't work in practice. Mainstream frameworks still aren't there.
2 replies 1 retweet 9 likes -
Replying to @cramforce @chadhietala
This is why structure matters so much. Tools like Ember, React (and CRA), and Angular are, today, razors without safeties: fine if you bring your own, worse than useless if you don't. Teams need budgets to constrain decision space and help hitting them; not blank canvasses.
1 reply 3 retweets 3 likes -
Replying to @slightlylate @chadhietala
Structure is important. I've never seen budgets work in practice. Either your stuff works by design or you're broken. Budgets then just make you feel sad, but don't fix things. They are
% the same as the USA debt ceiling.2 replies 0 retweets 8 likes -
Replying to @cramforce @chadhietala
We have dashboards and "can't regress" metrics for Chrome startup. Same challenge, different language. Team culture and willingness to Code Yellow for perf are critical.
1 reply 0 retweets 6 likes -
Can't stress enough how important bought-in leadership is. The willingness to put feature work on hold to keep the overall user experience good defines thoughtful management of technology products.
2 replies 6 retweets 19 likes -
The people who own these metrics need them to be reported on regularly and prioritize their improvement. Whole team needs visibility and constant reminders that "this matters".
1 reply 0 retweets 1 like -
So budgets aren't there to make you sad, they're there to help the org self-correct. They're a stand-in for more sophisticated metrics, but most teams I work with aren't in any position to own or develop their own metrics.
1 reply 0 retweets 4 likes -
Replying to @slightlylate @chadhietala
Start by changing your wording from budgets to metrics with controlling. There is no question that that is important. Code yellows are actually a sign for why budgets are so bad.
3 replies 0 retweets 1 like -
Code yellows are never good, but a consequence of budgets. Doing a ~yearly sprint to get back under target isn't healthy. Better than nothing, but still bad.
1 reply 0 retweets 0 likes
Of course that's bad. I'm not saying it's good. What I'm saying is that most orgs lack *even that* level of support.
-
-
(also, for the record, we haven't Code Yellow'd for startup time that I'm aware of, in part because everyone knows it's important and the tools support not regressing)
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.