Not to mention you have 2^100 states of on/off (~1.2676506e+30)

I work on that project. Every time some idiot starts talking about 'code coverage' my face turns red. Our code coverage is 1e-10%. Don't talk to me about this 70% bullshit.

Said with less vitriol:

It's not just code coverage that matters. It's the code path selection that matters. If you have a ton of branches and you've evaluated all of them once then yeah you sure might have 100% "coverage". But you have 0% path selection coverage since a single invokation of your API might choose true branch on one statement, false branch on another statement, and a second invokation might choose false branch on the first and true on the second.

While the code was 100% tested, the scenarios were not. What happens if you have true/true or false/false? That's not tested.

There's a term for this but I forgot what it is and don't care to go spelunking to find it.

> There's a term for this but I forgot what it is and don't care to go spelunking to find it.

sqlite calls this "branch coverage"

https://www.sqlite.org/testing.html#statement_versus_branch_...

> There's a term for this but I forgot what it is and don't care to go spelunking to find it.

Happy path?

Not quite what I meant, but that's another good description

At this point you're over-granularizing your services into nanoservices, which is an anti-pattern.

How does the service architecture affect that? Tim could be as protective of a code file as he is of a service. At least with a service you could work around it.

One way is that with different services, its more likely to have both a different language, framework, and paradigms -- that perhaps only Tim is familiar with (that's been my experience). Its definitely got a different repo, perhaps with different permissions.

But if you can explain to the team or the CTO why Tim is doing it wrong and how it is impacting X, Y and Z, then Tim will fix or be sent else where, no?

Tim accuses everyone else of being lazy or stupid.

Tom (real guy) was too busy all the time to do anything other than the 80/20 rule. He was too busy because he didn't share. So of course he was a fixture of the company...

but the CTO is a nice guy who just had a management training, so instead, both you and Tim are sent to a mandatory conflict resolution class

Each developer works in their own little silo and doesn't bother to learn the code outside their silo. Each team member developers their own idiosyncratic style. If they have to work with someone else's code, it's unfamiliar and they make slow progress and get cranky.

Now all the developers are going to the CTO or CEO and undermining the other developers, trying to persuade the CTO that so-and-so's code is shit.

No, not unless you’re somehow able to make the team, the CTO and Tim feel good at the same time. If you figure that part out let me know.

But if Tim's work is so bad that you can prove it..... How can a boss dodge the proof? I guess Tim should be fired second, the boss should go first...

> How can a boss dodge the proof?

This is a business decision, reality has no influence here.

That's why they invented the term "Business reality".