Hacker News Reader

Comment by doix | Hacker News Reader

But someone can figure it out. It doesn't matter that nobody knows anymore, if there's a real need with no alternative, someone can figure it out.

I used to work for a company that had an internal tool. It wasn't used anymore, everyone that worked on it was long gone, the source code was "lost".

There was some emergency and someone needed to use the tool to look at some old data. Lots of panic and people claiming it was impossible.

I opened up the executable in ollydbg, patched the executable so it worked properly, and life went on.

I'm sure the source code wasn't lost, it would have been on a tape backup that people were too lazy to try and recover.

If the source code is available then it's even significantly easier. I don't buy this whole "nobody knows how to update the code" reasoning.

If the code can't be updated, it's a matter of incentives and prioritization.

View on HN

> But someone can figure it out

Actually, in most cases - no, they can't. Or, rather, they can't figure it out as fast as they're "needed" to.

> if there's a real need with no alternative

What happens instead is that somebody with no real knowledge of software development says, "we need this change made in two weeks. We need this." That this might be impossible for any human being, living or dead, is completely ignored. If the programmer this is dumped on even suggests making any clarifying improvements to the code, even that is rejected because "we need" this.

And two weeks come and go, something was changed because there was a deadline, but the something that was changed broke a dozen other things nobody even remembers were there, and now there are bugs waiting to be discovered by unsuspecting users.

> it's a matter of incentives and prioritization

I know what you mean - it is, technically possible but it's never feasible because it's not predictable.

>Actually, in most cases - no, they can't. Or, rather, they can't figure it out as fast as they're "needed" to.

I've forensically self-onboarded a few times and yeah, it's at least 12x more expensive than well written docs + pairing.

It's economic for some projects but it's still crazy to do it if it's at all avoidable.

When you run up against this wall, it is often easier to write new software than to maintain the legacy code. Long term you are duplicating a ton of work at huge expense, but that is frequently the fate of successful projects: to be replaced with something sub-optimal that is nonetheless more tractable because there is less of it at the beginning and rapid feature development makes it easy to demonstrate value.

It’s definitely easier to write new code, but faster? I doubt it.

I see a lot of the time programmers doing the easy/fun thing rather than the hard beneficial to the business thing.

Part of this is resume driven development.

Loyalty gets you very little in today's climate. Why should I spend time understanding the current system that was developed on yesterdays hotness?

I need to spend my time here developing on the latest trends on a new solution (learning more from running into the same walls the current system did) - not learning the domain knowledge + old framework, so I can move on after a year and earn more at the next place.

Is this good for the world? No. But unless you want to swing the hammock and work at institions that value incumbents, the incentive is to do whatever work improves your resume, not what benefits the company.

I don't personally like it, and I often see old systems that are just fine get thrown out and replaced with the a less featured replacement that grow into the same kludge as the first, but I can't ignore that when you do that you learn way more and have better examples to point at in interviews.

>but I can't ignore that when you do that you learn way more and have better examples to point at in interviews.

"I replaced an unmaintained, buggy legacy tool with a new version with X new features" >> "I maintained a legacy tool"

> Why should I spend time understanding the current system that was developed on yesterdays hotness?

Simple. Because that is your job: to solve problems for the company using the current technology that the company has the resources to handle.

Also, the newest hotness is not as hot as you probably think.

It never is. But incentives drive behaviour, and the incentives for someone's career in this market pull in that direction.

More often I've seen that all that fast development time is spent trying to replicate features of the old system that were missed or deferred when designing the new system. Strangely, when they have achieved feature parity, the new system often doesn't seem so easy to work with.

> I don't buy this whole "nobody knows how to update the code" reasoning

Me too. At best, they would need the previous guys only in one condition: very short time constraint (have to figure it out "today"). Otherwise, it's not hard to figure out at all, even codes from a complete idiot. If he can code the program that worked, the code is very likely be figured out by experienced people very soon.

> be figured out by experienced people

Sure, you can figure out how to change it to do some very specific thing that somebody identifies as needed. What you probably can't do (at least not in any reasonable amount of time) is figure out all the things you're going to break in making this change. If they followed good software development practices, left a good comprehensive set of unit tests and documentation then you could do that - but they didn't.

> even codes from a complete idiot

If I was wrong, there wouldn't be anything wrong with global variables or goto statements - any code that "works" would be isomorphic to any other code that "works".

> identifies as needed

That's how it works even with the same guys on projects. If you think it would break (no tests found), write the tests first. I don't believe someone would write a complete mess million line of codes that works without some tests and docs, that would make him kinda genius.

And global vars and goto is not hard to figure out, it's hairy for sure.

> If they [...] left a good comprehensive set of unit tests and documentation then you could do that - but they didn't.

Then you can start by writing the tests. That forces you to dig until you actually understand what's going on.

This can be a lot of fun!

My "trick" is to write black box test without understanding the code. Like this:

1. Send in some data 2. Observe what data comes out. 3. Make a test asserting that! 4. Go back to 1.

> I opened up the executable in ollydbg, patched the executable so it worked properly, and life went on.

That makes you a great engineer that saved the day. Not all companies have great engineers that can save the day, or keep them, or even identify them.

Sometimes you also need to add features, which can be quite a task if you don't have the source code.

100% agree. One of my friends, in her first software engineering role, was handed a binder from 1987 and told to update some things.

Other coworkers had interacted with the system a little, but not extensively. It was a bunch of C for (rock & ore) mining software. It was intimidating and it took time, but she cracked it, and then happily (& justifiably) bragged that she added features to code that had been written before she was born!

I'd be proud if I were the original author, too. My code lived long enough that someone who wasn't even born when I wrote it was able to add features to it.

> I don't buy this whole "nobody knows how to update the code" reasoning

As an anecdote, your example demonstrates the truth of the reasoning. Absent extraordinary or unorthodox effort, such as patching the executable manually, programs do suffer from loss of understanding. Yes, you made it work, but can you really claim to understand the program and how it was written?

Of course, given enough time and effort, most code can be reverse engineered to a level of understanding good enough to work on it. In practice, most organizations are going to decide it's better to spend time and money on a replacement.

> I'm sure the source code wasn't lost, it would have been on a tape backup that people were too lazy to try and recover.

That's certainly one, rather uncharitable, way to look at it. But what constitutes sufficient effort, given time and money constraints in the real world? Unless that backup literally contained the only copy of information essential to the continued existence of the company, there's a limit. And what if they did find the backup, but it was on a magnetic medium that had degraded to unreadability?

I've made my career working on legacy code. There are definitely ways to understand systems even when nobody who originally worked on them is around, but business constraints have always determined whether or not the effort proceeds or is abandoned.

I think most devs don't want to figure it out. Let's face it, working with legacy code is just not fun unless the code is well written (and even then a lot of devs still don't want to touch it because it's "old tech" and doesn't help their resume).

Flip that: most companies don't want to pay what it costs to get someone to do this kind of work. Most devs would do it if the incentives were good enough.

Maybe in some companies developers work very hard and are short on time. Maybe you are in one of these companies yourself.

In my own experience, devs aren't often overworked and do have the time to do stuff like this. They just rather not spend the time on it for various reasons.

What incentives would get you to work on an old legacy project?

Are there consultancies that specialize in this kind of thing? "Help us kick this legacy can down the road the bit, nobody here understands it and it's not worth hiring for." Asking because I enjoy this sort of work :)

It's probably not much of a thing because companies don't want to spend a lot of money on maintaining legacy code, and are only willing to throw a lot of money at a problem when it's a huge emergency, but by then it's too late and your consultancy wouldn't be able to get the job done in time no matter how good you are.

Yeah, every consultancy. The ones that look like don't do that kind of work still do, because they somehow have the magic ability to turn a greenfield project into legacy code in the space of about 2 months.

My very first commercial program was a Fortran 90 thing that could write its own source code out to the filesystem if asked. Updated itself as part of the build. I still quite like that as a feature.

... Why would that be useful? Don't you have the source code in front of your face as you are working on it?

> ... Why would that be useful? Don't you have the source code in front of your face as you are working on it?

Maybe not, actually. Assuming that the code was written in the 90s, there probably wasn't any version control (only backups at specific milestones).

With no version control, there's a 50:50 chance that the source code you found for some deployed version is not the same as the code that was backed up.

Replying to a post saying > the source code was "lost"

Sure, I had source that I had written. In source control even, was using fossil. But I thought my binary might end up somewhere decoupled from that source, with some other engineer tasked to modify it, and I hope they find the dump source option listed under -help useful.

> It doesn't matter that nobody knows anymore, if there's a real need with no alternative, someone can figure it out.

Well, by that logic, someone can build it from scratch.

> I opened up the executable in ollydbg, patched the executable so it worked properly, and life went on.

I've done simple binary patching, and thank my lucky stars that:

1. The replacement configuration value strings were shorter than the original

2. It was written in C, using nul-terminated C strings

If this was almost any other language, I would have more work even if the replacement string was shorter, because I'd have to fix a bunch of offsets everywhere.

what was the update? the kind of update that "programming as theory building" is talking about is like, the next version of a piece of software.

Yes, but the comment I replied to implied that software will just stop working. If software has been working for years and then stops working, it's usually something fairly small than can be hacked quickly.

In my specific case, the tool had a whole bunch of hardcoded values. It checked authorization against an LDAP server, that all changed. Connected to a sql sever that moved + credentials changed. Assumed certain files existed on certain network drives which were moved.

Technically, it could have been solved by faking all the infrastructure. It also could have been solved by digging out the source code from tape drives. But everyone was running around saying it was "impossible". I was shocked how quickly people tossed out "impossible".

It could have been done with a simple hex editor, but the new values were longer than the old values, so the strings didn't fit. I put the new strings at the end of the .data section and then just changed a bunch of offsets.

I agree that if you're writing the next version of the software, you can't do that quickly when nobody knows how the current version works. But chances are, you're not writing the next version of the software quickly even without churn.

it's not really about how the software works. the source code says what it's doing. the thing is the source code is the product of a theory; a theory determines how you respond to the world. if that theory is lost, then updating--in the long-term sense--becomes hard, because the theory that you form might (probably) be incompatible with the theory that made the software. this incompatibility might make producing functioning software difficult, but more likely, the mismatch will make choices that don't make sense to, say, users, appear to be the obvious thing to do.

Reply on news.ycombinator.com