Live data from Hacker News

Ask HN: Worst code you ever had to fix up?

news.ycombinator.com

1–10 of 25 posts

Re: Ask HN: Worst code you ever had to fix up?

#2
I actually left a job once because not only was the code bad, but my manager wanted me to effectively lie to make him look better.

Ran out as soon as I could. In general it's worth remembering that if your overall team isn't performing well you still can be fired regardless of what your immediate manager thinks.

For better or worse I had a childhood which taught me not everyone's going to like me, but you just need to find people who do. In the case of employers I've left several places where I just didn't like the culture. It's worked extremely well for me.

Re: Ask HN: Worst code you ever had to fix up?

#3
People want greenfield projects, but maintaining and improving legacy code is where the real, fundamental learnings occur ;).

Probably the cruftiest code was a ship autopilots UI code that was 20k lines of C in one file with no automated testing. There was a very manual process for loading code onto a test display. The debugging experience was terrible. There was a way to manually inspect memory addresses, but that was about it. Oh and there were threads, managed by the homegrown OS (basically just a scheduler that ran on a 10 ms ticks or on an interrupt). These threads had priorities so they could a sometimes get into deadlocks waiting for each other.

As insane as it was, it was the best learning experience I could have had. I’m glad I stuck with it. I learned a lot about low level systems, prioritizing the highest value refactoring, and introducing automated testing to a legacy code base.

Re: Ask HN: Worst code you ever had to fix up?

#4
I've worked with a million lines of C++ code written by a guy who doesn't understand C++. There's a 10k line loop that's "Unabstractable" according to my former boss. Everything stored custom linked lists, even trianglated meshes. Copy and pasted code everywhere. Maybe I should leave the organization.

Re: Ask HN: Worst code you ever had to fix up?

#5
I work for a US-based company that has been trying to expand overseas for a decade or so by acquiring smaller companies overseas.

When we expanded into South America we bought a Brazilian company. I guess it didn't work out because within 2 years the company decided to shut down the Brazilian office and (unfortunately) all of the Brazilian-based developers were let go.

The website was handed over to us, and we were tasked with updating it to reflect the office was shutting down. It was written in a PHP framework I've never heard of, the dev and the prod websites were running on the same server, and it was obvious development was completed via SSH on the box itself. No git repo or pipeline or testing framework or anything like that.

We tried saving it but after 2-3 days we gave up and converted over to a static site hosted via S3.

Re: Ask HN: Worst code you ever had to fix up?

#6
There's poorly-architected due to lack of understanding: ignorance and/or incompetency.

Then there's negligence like interns throwing code at a wall, not caring about quality, and managers not doing code reviews. Oh, and it's code shared across several product lines in hundreds of products. A+ guys for letting me clean-up your "science experiment" dishes. You got your giant wall of dead code, your commented-out code, debugging instrumentation code, unfinished code, code that duplicates code elsewhere, and code no one understands because they didn't document it.

Re: Ask HN: Worst code you ever had to fix up?

#7
Refactored and rewrote a >100k LOC expert system in the medical field. This was a single Java source file with one long if else tree. Everything was hard coded constants. It was like "if (setting.equals(foobar)) { if (a == 1 && b == 10 && ...) { sendAlert(); } }"

There was no testing and no documentation of the feature sets involved. Rewrote the code in under 10k LOC, huge cost and performance improvements were had, and the feature set was documented. Other engineers could look at the code and maintain it. Got the critical sections of the expert system to 100% branch coverage. Had to fight against other engineers who were saying "100% coverage is bad! I read that on medium!" I just did it anyway due to my own ethical concerns of writing bad software in this area and it only took me ~4hr more to get from 80% to 100% critical path code coverage.

Some of the most stressful software I worked on. I added in shit loads of logging to make sure that if anything did go wrong we'd find out what happened.

At some point someone wasn't notified about something the expert system was supposed to catch. I felt like I was going to faint because this meant someone was seriously hurt. Unfortunate twist: my code worked correctly. The system on the other end who was supposed to send the alert (maintained by the "100% coverage is bad" guy) died. Very unfortunate. The other engineer didn't feel bad about it at all.

I think about this a lot when I'm speaking to engineers. I use it as a litmus test for who I really enjoy working with. If they read a medium article and can't apply critical thinking to identify if it relates to their circumstances or not. Also, attempting to find out if they refuse to hear out a coworker.

Re: Ask HN: Worst code you ever had to fix up?

#8
Oh plenty bad. Think of brittle C applications where everyone is afraid to touch anything since it might break. Type systems might not help you code faster, but they do decrease the worry of changing things later. You have to basically find or create abstraction boundaries in the code, then lift out localized balls of cruft and replace them a piece at a time. Or put another way, I usually prefer to edit with emacs, but sometimes you have to just plan on editing with rm.

Re: Ask HN: Worst code you ever had to fix up?

#10

People want greenfield projects, but maintaining and improving legacy code is where the real, fundamental learnings occur ;). Probably the cruftiest code was a ship autopilots UI code that was 20k lines of C in one file with no automated testing. There was a very manual process for loading code onto a test display. The debugging experience was terrible. There was a way to manually inspect memory addresses, but that w…

Oh yes, legacy is the best place to learn. You replace something that's 'working' with something that keeps working but better. You write tests against a working system. The thing is already giving value, so you don't have to worry about that. And usually the problems are more and more complex as the code 'matures' so challenge. I don't like working on big greenfield projects. Give me a somehow working big ball of mud codebase to steer and I'm a happy man.
Post reply on HN