The code is a freaking mess. Shared behavior, terrible variable/method naming, misleading module naming, dynamic polymorphic spaghetti, whitespace errors, no consistency, confusing even if you understand what the code is doing, ... . It should never have passed code review. It probably wasn't code reviewed.

The comments are sparse and useless. Quality level: // This is bridge.

The documentation does not exist.

Testing steps for QA are missing several steps, including setup, so actually using the feature is bloody challenging. If one thing is wrong, the feature just doesn't show up (and ofc won't tell you why).

The specs for the feature are outdated and cover only 4 of 19+ cases. And are neigh useless for those 4.

The specs for the report I'm fixing don't even check the data on the report; it just checks for one bit of data on each row it creates -- a name -- which is also the same on each row. gg.

The object factories (for specs) are a mess, and often create objects indirectly, or in backwards order with odd post-create overwriting to make things work. Following the factories is a major chore, let alone fixing or extending them.

The new type has practically zero test coverage.

The factory for the new type also only creates one variant -- and does so incorrectly.

And to top it all off: the guy who wrote the feature barely ever responds. If he does, he uses fewer words than my bird knows, then stops responding. I've yet to get a useful answer out of him. (and he apparently communicates just fine, according to my micromanager.)

But "it's just fixing a report; it'll be easy!"
Oh, fuck off.

How fucking hard is it to remain consistent with naming, holy shit! Is it register, sign up, create user and is it user, client, customer, account.. then you have the API to contend with, with it's own terminology! This is such crap.

Buffer usage for simple file operation in python.

What the code "should" do, was using I think open or write a stream with a specific buffer size.

Buffer size should be specific, as it was a stream of a multiple gigabyte file over a direct interlink network connection.

Which should have speed things up tremendously, due to fewer syscalls and the machine having beefy resources for a large buffer.

So far the theory.

In practical, the devs made one very very very very very very very very stupid error.

They used dicts for configurations... With extremely bad naming.

configuration = {}
buffer_size = configuration.get("buffering", int(DEFAULT_BUFFERING))

You might immediately guess what has happened here.

DEFAULT_BUFFERING was set to true, evaluating to 1.

Yeah. Writing in 1 byte size chunks results in enormous speed deficiency, as the system is basically bombing itself with syscalls per nanoseconds.

Kinda obvious when you look at it in the raw pure form.

But I guess you can imagine how configuration actually looked....

Wild. Pretty wild. It was the main dict, hard coded, I think 200 entries plus and of course it looked like my toilet after having an spicy food evening and eating too much....

What's even worse is that none made the connection to the buffer size.

This simple and trivial thing entertained us for 2-3 weeks because *drumrolls please* none of the devs tested with large files.

So as usual there was the deployment and then "the sudden miraculous it works totally slow, must be admin / it fault" game.

At some time it landed then on my desk as pretty much everyone who had to deal with it was confused and angry, for understandable reasons (blame game).

It took me and the admin / devs then a few days to track it down, as we really started at the entirely wrong end of the problem, the network...

So much joy for such a stupid thing.

The two hardest things in software are naming things, cache invalidation, and avoiding off-by-one errors.