Remix clone Hacker News

I'd prefer maintainable programs of any size.

Other than non-trivial academic samples, the odds of a program needing to change over its lifetime or large, and it's current apparent correctness has little to do with someone else adapting it to the ever changing environment.

The number of times I've heard "it seems to work and we don't dare change it" is far too many

▲

jffhn 2 days ago | parent | next [-]

>"it seems to work and we don't dare change it"

What they mean is: "we don't understand it and we don't have good tests, so there is a high probability that it doesn't work and that doing even the most trivial and seemingly harmless modification would cause an issue to surface, so we don't dare to change it else we wouldn't be able to pretend that it works anymore and might have to fix a lot of issues that we would have a hard time to even understand"

▲

azeirah 2 days ago | parent [-]

Yeah.. The dumb thing is that it isn't even _that_ hard to fix this kind of stuff... It does take time and commitment though.

But _hard_? No.

▲

riehwvfbk 2 days ago | parent | next [-]

But that is hard.

I think you (and many software developers) are using the word "hard" to mean "intellectually challenging", as in "Leetcode Hard". But things that require a lot of effort, time, and coordination of people are also hard, just in a different way.

Imagine a codebase with a wart. And yes, without enough tests. Let's say the wart annoys you and you want to fix it. But first you have to convince your employer to let you spend 6 months backfilling missing tests. In the meantime they will pay your salary but you will not work on the features they want. You will be working on fixing that wart. Convincing management: easy or hard?

OK, so you got them convinced! Now you can't just fix the wart. First you have to slog through a big refactor and write a bunch of tests. Staying positive while doing this for 6 months: easy or hard?

Do you stop other teams from writing more code in the meantime? No, so does the new code come with tests? How do you make sure it doesn't depend on the old "warty" interface? You need a compatibility layer. You need to convince other managers to spend their teams' cycles on this. Easy or hard?

OK, the refactoring is done. You release the new software. But, despite all your efforts you overlooked something. There's a bug in production, and when a post mortem is done - fingers point at you. The bug wasn't introduced in pursuit of a new feature. It was part of an effort to solve an obscure problem most people at the company don't even understand. To them, the software worked before, and it doesn't work now, and it's always those nerds tinkering with stuff and breaking things. Convincing these people to let you keep your job: easy or hard?

Perf review time. Your colleague shipped a new feature. You shipped... that thing that broke prod and nobody understands. Getting a raise: easy or hard?

And that is why these warts fester. The end.

	▲	polishdude20 2 days ago \| parent [-]
		The first easy or hard question should be "There is a wart that annoys you, is it really that bad?"

▲

jffhn 2 days ago | parent | prev | next [-]

Some people learned to be fearful.

At some point I was working on a piece of software we knew inside out, had good tests for and often ran through hand curated stress tests for benches, analysis or just exploratory testing, so we had a high confidence in it and in our ability to modify it quickly and successfully.

Some day executives were visiting and we had to do a demo of our system interacting with another one. Until the last minutes we were happily modifying our code to make the demo better. A guy from other system's team saw that, freaked out, and went straight to our boss, who then laughed with us at how scared the guy was. It turned out his team was not at all that confident in their system.

▲

marcosdumay 2 days ago | parent | prev | next [-]

Will you have time to commit to it?

If it's in a professional setting, it's most likely to not be a hard problem, but actually an impossible one.

▲

dragonwriter 2 days ago | parent | prev [-]

It’s a hard social problem in many contexts, even if it is not a hard technical problem.

▲

necrotic_comp 2 days ago | parent | prev [-]

I get this a bit at my job, and I think there's a difference between making changes (which I do a lot of) and being confident in the changes that you're making. The environment I'm in is completely fault-intolerant, and we're currently hamstrung by our hardware (e.g. no backups/no secondaries/etc.) so changes that we're making have to be well-reasoned and argued before they're put in.

Some people take that as being scared, but it's more like "you have to have made this work and tested it before putting it in."