3 ms·

> I can't win this battle You are fighting the wrong battle. You harp on the technology used rather than the specific functionality you desire. The bad way to

> I can't win this battle You are fighting the wrong battle. You harp on the technology used rather than the specific functionality you desire. The bad way to do it: "You made a single page app with PHP and {other tech} and {database}! I hate those! Don't you read (reddit, twitter, hacker news)? Best practices say..." The good way to do it: "Our users often share links within the application with each other to navigate and the new single page app you demoed doesn't allow that." Or: "While the page load times look great on the metrics in your power point, as everything is lazy loaded it takes 10 seconds for the page to actual become usable, the old site loaded in under a second why are we regressing the user experience here?" Or the evergreen: "What does that buy us?"

stavros 2y ago
This is fairly basic advice, and it feels a bit insulting to assume I'm just hating on some tech. Obviously, if things were as easy as "here's the immediate and unambiguous problem with this approach", I would have gone that way. Things would be great if the risks were as simple as this. The actual problem is "six years later, the frontend is a ball of spaghetti code and it takes you two sprints to change a component". How many developers do you think heed those warnings?
- j45 2y ago
  Not enough. But they will scoff at other technologies old and new.
- willcipriano 2y ago
  > heed those warnings It's not a warning. It's a functional requirement that you put into the ticket. The project isn't done if the rewritten page takes longer to load than the old one did. Don't ship it, don't pay bonuses based on shipping it.
  - stavros 2y ago
    Please read my comment more carefully, you're being patronizing. I can't put "I want feature development on this codebase to be faster than two sprints in six years" in the requirements.
    - willcipriano 2y ago
      Sounds like you should talk to the person who is actually in charge then.
      - stavros 2y ago
        I'll have a chat with the mirror.

stavros 2y ago

This is fairly basic advice, and it feels a bit insulting to assume I'm just hating on some tech. Obviously, if things were as easy as "here's the immediate and unambiguous problem with this approach", I would have gone that way. Things would be great if the risks were as simple as this. The actual problem is "six years later, the frontend is a ball of spaghetti code and it takes you two sprints to change a component". How many developers do you think heed those warnings?

j45 2y ago
Not enough. But they will scoff at other technologies old and new.
willcipriano 2y ago
> heed those warnings It's not a warning. It's a functional requirement that you put into the ticket. The project isn't done if the rewritten page takes longer to load than the old one did. Don't ship it, don't pay bonuses based on shipping it.
- stavros 2y ago
  Please read my comment more carefully, you're being patronizing. I can't put "I want feature development on this codebase to be faster than two sprints in six years" in the requirements.
  - willcipriano 2y ago
    Sounds like you should talk to the person who is actually in charge then.
    - stavros 2y ago
      I'll have a chat with the mirror.