|
|
|
|
|
by PragmaticPulp
1261 days ago
|
|
> They had a whole team dedicated to building a shitty front end component library that we all had to use to reskin our apps in order to achieve design consistency. We could've used a mature tool like MaterialUI but nooooooo, this hot mess of a component lib was our great gift to the open source community. My favorite part: we constantly ran into cases where the provided components didn't meet all of our UI behavior needs, but the development backlog for the UI team was 2 years so we had to fork the components and make our own changes, which other teams were doing as well. It was the worst of all worlds. I've watched this exact story play out twice now: Company grows rapidly. Front-end middle managers hatch a plan to make a shared component library that will solve everyone's problems. Open sourcing it becomes a goal, because the developers want something for their resume. Project turns out to be much, much harder than they expected. All of the teams trying to deliver actual work are constantly stuck behind the shared component library team's backlog. Nobody can accomplish even basic tasks because they're all blocked on the component library. Devs from every team start working on the component library in an attempt to get anything done. Clashes ensue. it's possible to have a good component library for the company to use, of course. Carving out a separate team to do it separately from everyone else and requiring everyone to go through that team is an obvious point of failure. Yet it seems to happen over and over again for some reason. |
|