8 ms·

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 wo

• pasquinelli 4y ago
  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.
  • doix 4y ago
    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.
    • pasquinelli 4y ago
      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.
• Existenceblinks 4y ago
  > 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.
  • commandlinefan 4y ago
    > 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".
    • Existenceblinks 4y ago
      > 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.
    • mike_hock 4y ago
      > 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.
      • BurningFrog 4y ago
        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.
• fathyb 4y ago
  > 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.
• deleted 4y ago
  [deleted]
• commandlinefan 4y ago
  > 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.
  • pydry 4y ago
    >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.
  • flatline 4y ago
    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.
    • simmerup 4y ago
      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.
• charlie0 4y ago
  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).
  • lmm 4y ago
    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.
    • charlie0 4y ago
      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?
• civilian 4y ago
  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!
  • AnimalMuppet 4y ago
    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.
• laserlight 4y ago
  > 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.
• deleted 4y ago
  [deleted]
• cratermoon 4y ago
  > 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.
• JonChesterfield 4y ago
  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.
  • vkou 4y ago
    ... Why would that be useful? Don't you have the source code in front of your face as you are working on it?
    • lelanthran 4y ago
      > ... 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.
    • JonChesterfield 4y ago
      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.
• andrewf 4y ago
  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 :)
  • midoridensha 4y ago
    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.
  • BigJono 4y ago
    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.
• lelanthran 4y ago
  > 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.