[mrazomor]

In my case, it was the integration testing framework built for a large Python service.

This was ~10y ago, so my memory might not serve me well. A bit of context:

- proprietary service, written in Python, maaany KLOC,

- hundreds of engineers worked on it,

- before this framework, writing the integration tests was difficult -- you had a base framework, but the tests had no structure, everyone rolled out their own complicated way of wiring things -- very convoluted and flaky.

The new integration tests framework was build by a recently joined senior engineer. TBF, it's wrong to say that it's was a framework, if you think in the xUnit sense. This guy built a set of business components that you could connect & combine in a sound way to build your integration test. Doesn't sound like much, but it significantly simplified writing integration tests (it still had rough edges, but it was 10x improvement). It's rare to see the chaos being tamed in such elegant way.

What this guy did:

- built on top of the existing integration tests framework (didn't rollout something from zero),

- defined a clear semantic for the test components,

- built the initial set of the test components,

- held a strong ownership over the code -- through the code review he ensured that the new components follow semantics, and that each test component is covered by its own test (yep, tests for the test doubles, you don't see that very often).

Did it work well longterm? Unfortunately, no. He stayed relatively short (<2y). His framework deteriorated under the new ownership.

Travis, if you are reading this and you recognized yourself, thank you for your work!

[MathMonkeyMan]

I wonder if this is a tragedy of "the org wasn't ready for his solution" or more of a "if I were to go back now, I'd notice it wasn't so good."

[f1shy]

Without knowing anything, and before reading this comment, I had the feeling of nr. 2. Strong feeling. I think the reason is „many klocs of Python“. I have developed alergy to big Python programs. I like python for small things, probably wrapping some C code.

[__rito__]

What languages do you personally prefer for many KLOCs of code?

[bboygravity]

Why would KLOC in Python be worse than in any other language?

[mrazomor]

It's about the different ways the language allows you to shoot yourself in the foot.

I worked on large Python, C++, Java & Go services. I have 10y+ of experience with the first 3. C++ allows you to write incomprehensible code (even to the experienced C++ devs) and justify its existence (because of the performance gains). But you need to be a top expert to write a compileable code of that type. I'm comfortable with diving in any C++ codebase except for the libraries like std, boost, abseil, folly, etc. Most of the code there is absurdly difficult to comprehend.

On the other hand Python leads in the ways a junior dev can introduce hell in the code. Especially if the team doesn't rely on the strict type check. I have seen horrors.

I was bewildered when I realized that working with JavaScript with type checks (Closure compiler) was insanely more productive and smooth than working with Python (before the type checks).

That's why Java won the enterprise world. It takes an effort to make a mess in Java (but people still manage). Go is in a similar place.

[munch117]

Because you're doing more work per line.

A 20 KLOC Python program is not more complicated than the 100 KLOC C program performing the same function. Quite the contrary. But if you're comparing 100 KLOC of C to 100 KLOC of Python, the Python program may seem unwieldy.

[yosefk]

So 500 KLOC of C doing the same thing would be better?..

[munch117]

Not at all.

But when you come across 500 KLOC of C, then you say "wow this is big" and you're forewarned that this is going to be unwieldy. You may underestimate the 100 KLOC of Python. That's all I'm saying.

[bornfreddy]

Why only those two options? It could be just "the company had other priorities and developers, while they appreciated Travis's work, didn't find it worthwhile to carry the torch themselves". Having a great testing framework is just one of the things that need devs' attention.

[MathMonkeyMan]

Fair point, it's a false dichotomy; though your example is close to "the org wasn't ready for it," which is itself vague.

Maybe the issue is that it easily comes apart without a dedicated censor, so to speak, and nobody wanted to have that role.

[PartiallyTyped]

> Did it work well longterm? Unfortunately, no. He stayed relatively short (<2y). His framework deteriorated under the new ownership.

I think the issue is that integ tests are not really a place that sees "development". You write the integ tests, and move on, you are not actively introducing more integ tests.

I think that's a shame that this is the common view of the people that need to fund this. Bad integ tests mean bad dev exp, which then results in increased attrition and dissatisfaction.