I was definitely a jerk but in my defense they were batshit crazy

A couple of years ago I was working at a start up and they had a “no jerks” policy that they eventually used to fire me. I personally thought that was unnecessary because if they had just said, “We’re not going to let you improve the software architecture in a meaningful way” I would have left. We were the “engineering” team, which you know I have a problem with already because we simply don’t “engineer squat” in software development. I mean, I want to but…hey, I need your help to do engineering.

The think I did that got them to use the “no jerks” rule was that during a team meeting I suggested that my colleague’s suggestion was “the dumbest thing I’ve ever heard.” This was after about 45 minutes of me literally begging them not to go down this path and to do anything else. Now the details of how I became a jerk don’t really matter, but something about that has bothered me every since and I could never verbalize it until now.

The part itching at my brain for the last couple of years should matter to you too. So what was it?

We were arguing over testing. The javascript lead was arguing that they should “hack the visual studio project to run tests within the source projects of the javascript folders.”

When I started at the start-up, there were about 4 projects in their visual studio solution. They had ZERO dependency management in their code base. Basically they had let the JS devs run the VS solution structure. Since JS uses folders for it’s dependency management they just did the same thing in VS.

If you’re a VS (C#, F#, C++) dev you’ve already come over to my side of this argument. Jerk or not, putting everything in folders in one massive project is LITERALLY INSANE in the dotnet world. In fact, that’s literally what they had. The 4 projects were forced on them as they had a “nightly jobs” project that they wanted to deploy separately that depended on the “big one.” At some point another developer that they “had to fire” added a test project. This was empty btw. So yeah, it was a disaster.

I did my best to fix the portions I worked on without effecting the rest of the team. But as you can imagine my efforts required MASSIVE refactorings. Which I was able to do but the introduction of new, tiny projects, that cleaved off reusable bits of logic drove them NUTS. Isn’t that crazy?

And along the way I started introducing tests for these tiny projects. I would even run the tests from time to time and find issues — quickly, often before the team knew there was an issue.

Okay. So what about the JS devs and this idea about testing?

As I introduced more projects they came with more and more tests. Some of them were in the form of test clients and only meant for me during development. But many were normal unit and integration tests. The team began to realize that these tests had my back. They wanted the same thing, BUT THEY HAD A BIG PROBLEM.

Virtually all of the testing tools make the assumption that the tests and the thing being tested are in two separate locations.

Even adding tests as separate projects would be validation of me in our now over-a-year-long-battle about whether the solution should contain multiple projects. [I’m not joking — they wanted it to stay at the original 4.]

To add tests in VS/dotnet/java/every-framework-known-to-humankind you put them in a separate place so that you can manage the tests separately. For example, it’s unusual to deploy test code. Usually the packages (projects in VS/dotnet) containing tests are not included in the deployments.

Essentially they wanted to hack the VS solution/project files rather than admit that they had been on the wrong side of the more and smaller projects debate they had been having with that jerk Scott. Ha.

So what’s the take away here? What was it that had been itching at my brain for years?

Today I realized what had been bothering me: THEY WERE USING TESTS FOR EVIL

You see this all the time now with refactoring. It’s gotten to the point that if anyone says the word “refactoring” in a planning meeting they (virtually) mean, “Oh, we screwed that up. I’m going to need to rewrite it on the down-low. To fool the noobs/PM we’re going to call what we’re doing ‘refactoring’ but we’re absolutely doing rework/rewriting.” Refactoring for evil. Remember, when Martin coined the phrase refactoring it was specifically for good: Refactoring: Improving the Design of Existing Code ( https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599/ )

This is all the more egregious because testing in general is spoken about in a virtuous way. We are “good developers” if we have “good testing practices.” But here they were using testing for evil. No way Scott was right about the solution structure and dependency management! (And I’m not exaggerating. The “idea” of how to do dependency management had become, as it so often does, confused with “Scott’s opinion.” Like I invented dependency management or something. I can assure you that NOTHING I argued with those guys was Scott’s opinion while being absolutely certain that they thought they could change my mind. Oh, brother!)

So why do I say, for evil? Because in both cases if the thing you’re doing is to hide something worse.

The guys doing the “refactoring” don’t want better design processes.
The guys doing the “testing by hacking the project” don’t want better design processes and dependency management.

These evils will prevent you from being able to do quality architecture. More importantly, it’s impossible to do the-method or it’s sub-parts like volatility based decomposition and design using the taxonomy design language of the method. It’s not possible because of the evil being done.

And I’m specifically using the word evil here because of it’s ethical implications. It’s obvious to any of you reading this that no matter how big a jerk I was that the other people were literally dooming what amounted to millions of dollars in software and development effort that was measured in man-years to the garbage bin. And that’s not hyperbole. Enough time has passed that I know that has happened. I’m not excusing my jerkish behavior, but I am suggesting that both getting rid of me and doing things like hacking the vs solution were unethical moves meant to allow the continued unethical behavior to continue.

This is a weird topic because I feel like people are uncomfortable saying these things are unethical. And yet, given all available context, to continue to do them is wrong. And worst of all are to do even more things to ensure that these behaviors will become enshrined.

I studied electronics so to me these evil practices are like internal resistance in electronic components that only generate heat. They don’t make the end product completely useless, but they create heat that is a complete waste. In the same way that naming is still one of the “unsolved problems in software” “waste heat” is still the unsolved problem in electronics (it’s why everyone wants the magic room temperature super-conductor).

Inevitably when one of these tales is related someone will suggest that maybe there was a better way to reach agreement or consensus on these things.

I’m not ruling that out but when I finally got frustrated and said, “That’s the dumbest thing I’ve ever heard,” I was not joking. It was so clear that we had gone so far off the rails that no amount of my nuance and patience and dialog skills would fix this problem. The javascript guys just wanted the .net solution to manage dependencies like an NPM package and no amount of my skills were going to change that.

And just to make that last point super clear, even the developers of NPM packages put their tests in different paths than their source code. The thing they do differently is dependency management in JS is largely managed by config files. In Java it’s managed by Jar+namespace and in dotnet it’s done by DLL+namespace. They had gone so far down the wrong path that they had just become evil and, like most people doing evil, they had lost the perspective to see it.

I can’t fix that for them.