17 javascript trackers is a solution to a problem, not a problem in itself. You don't need 17 javascript trackers to creep on your users. In fact you don't need to creep on your users at all. So the real problem is the simplest possible problem: there's no problem at all. So the 17 javascript trackers are 100% accidental complexity in the solution to a nonexistent problem.
Controlling how a checkbox animates when you check it is also a solution, not a problem. Problems are things like: users don't know whether they've selected this value or not. Users think our application is boring. Users are completing their tasks too quickly and we need to find ways to annoy them and destroy their productivity. All of those are the possible problems that micromanaging a checkbox's animation might solve. There are almost certainly simpler ways to solve those problems.
Adding an abstraction with thousands of lines of code is, obviously, not a problem, it's a (probably poor) solution. I don't understand why I need to explain this one.
The rest of it is suggestions on how to let go of your overly complicated solutions and find more simple ones.
The article, and most commenters, are basically assuming a fixed, relatively complex problem. Your point seems to be that experienced professionals should not work on simple problems. Okay? And you should wear your seatbelt while in a car. That has nothing to do with finding simple solutions to a fixed problem.
No, 17 javascript trackers IS a problem - because somebody in your org or your client's org wants them there, and somebody else has accepted that request and is taking money for it and thus it has become your task.
A "simple solution to the problem" could be to abstract away the tracking code into a system of well documented and typed generic internal events with a plugin architecture. Rather than scatter hundreds of tracking calls everywhere you just need one in each place. Then write a plugin for each of the damn trackers to translate those internal events into whatever is required for each tracker.
Getting rid of all the trackers is avoiding the problem entirely. I agree, that's what we should do! But it's not a valid answer when your boss comes to you and says "now we're adding 17 javascript trackers, and yes we do have to do it".
The checkbox animation is your problem, as the developer, because the designer has decided that's what should be done and has already sold the concept to the customer. The designer is an idiot, but an elegant technical solution to the task of animating the damn checkbox is not "I've decided not to do that becuase you guys are idiots". Not doing it is just doing something simpler instead.
Controlling how a checkbox animates when you check it is also a solution, not a problem. Problems are things like: users don't know whether they've selected this value or not. Users think our application is boring. Users are completing their tasks too quickly and we need to find ways to annoy them and destroy their productivity. All of those are the possible problems that micromanaging a checkbox's animation might solve. There are almost certainly simpler ways to solve those problems.
Adding an abstraction with thousands of lines of code is, obviously, not a problem, it's a (probably poor) solution. I don't understand why I need to explain this one.
The rest of it is suggestions on how to let go of your overly complicated solutions and find more simple ones.
The article, and most commenters, are basically assuming a fixed, relatively complex problem. Your point seems to be that experienced professionals should not work on simple problems. Okay? And you should wear your seatbelt while in a car. That has nothing to do with finding simple solutions to a fixed problem.