Few jobs ago I was a PM director at a scaleup and at some point our frontend platforms engineering (or something like that) came into my purview.
This team didn't build front end experiences but tried to build out tooling in which other devs would. Which was weird to me given that we didn't do anything extraordinary in terms of experience so off the shelf stuff should have worked.
I think this was some evidence towards the point in this article. Two things were at play:
First, the gross complexity of the available frameworks made it seem like something like this was necessary.
Second, the people involved were excited to further their careers on this, so motivation to call out unneeded complexity was low.
If I had owned this space from the start, I'd have asked the question of "what business outcomes does this enable which we can't achieve at least for a while, with static-ish html, forms, etc" and maybe allow a little complexity where justified. But since it was purely engineering owned for a few years before it got to me, it was way too late to reign the complexity and we ended up doing shit like porting from one framework to another.
> the people involved were excited to further their careers on this, so motivation to call out unneeded complexity was low.
I strongly disagree. The fact of the matter is frontend tech debt is just SO MUCH cheaper than backend tech debt.
If all you need to do to is refactor or port over a SPA and leave the existing API alone, you've sidestepped so much pain it's unreal.
If you started out with "simple" form requests instead of an API, the backend is pretty much guaranteed to be an undisciplined mess. Wrong place to cut corners.
> The fact of the matter is frontend tech debt is just SO MUCH cheaper than backend tech debt.
Seeing someone mention this as an opinion, let alone asserting it as fact, is a first for me!
I had the opposite impression, but I'm not sure how I'd debate it as fact without some observational analysis of dependencies and frequency of breaking changes in various frontend and backend projects.
Would you prefer to be on call at 2am to immediately fix something that blew up on the backend that caused an outage, or be given a couple of days to just patch a weird bug that only affects a few users on the frontend?
If you said frontend bugs are cheap I'd agree with you.
But when you say tech debt o don't think about bugs I think about updating dependencies and dealing with their breaking changes. That feels worse to me in frontend code than in backend code. Not for some intrinsic reason but I guess just culturally.
I don't even know if I disagree with you on these details.
The point is we bit off too much complexity on the front-end when we shouldn't have had to given the vanilla nature of what we did in terms of user experience, but somehow nobody on the eng side questioned it. For me as a dev turned PM it was screamingly obvious.
Front end debt is only cheaper in the sense that it’s running on someone elses hardware so when it fails you don’t see it fail or the impact of it’s failure
This team didn't build front end experiences but tried to build out tooling in which other devs would. Which was weird to me given that we didn't do anything extraordinary in terms of experience so off the shelf stuff should have worked.
I think this was some evidence towards the point in this article. Two things were at play:
First, the gross complexity of the available frameworks made it seem like something like this was necessary.
Second, the people involved were excited to further their careers on this, so motivation to call out unneeded complexity was low.
If I had owned this space from the start, I'd have asked the question of "what business outcomes does this enable which we can't achieve at least for a while, with static-ish html, forms, etc" and maybe allow a little complexity where justified. But since it was purely engineering owned for a few years before it got to me, it was way too late to reign the complexity and we ended up doing shit like porting from one framework to another.