5 ms·

It's funny. My first step would be 0. You reach out to the previous maintainers, visit them, buy them tea/beer and chat (eventually) about the codebase. Lear

It's funny. My first step would be 0. You reach out to the previous maintainers, visit them, buy them tea/beer and chat (eventually) about the codebase. Learned Wizards will teach you much. But I didn't see that anywhere. I think the rest of the suggestions (like get it running across platform, get tests passing) are useful stress tests likely to lead you to robustness and understanding however. But I'd def be going for that sweeet, sweet low-hangin' fruit of just talking to the ol' folks who came that way before. Haha :)

Night_Thastus 3y ago
IME, this only works if you can get regular help from them. A one-off won't help much at all.
- keepamovin 3y ago
  Yeah you need to cultivate those relationships. But with a willing partner that first session will take you from 0 to 1 :)
  - mst 3y ago
    A lot of the time it takes you from 0 to 0.1, but (a) every little helps (b) if you take them out for lunch or a post-work beer or whatever it can build a relationship where you can ask follow up questions via email. Ideal is if they have a life such that something morally equivalent to "how about we meet up and I'll pay for the food/beer" is a viable thing to suggest later. Oh, and always remember - the way to a geek's schedule is often through their wife. If you get a chance to meet their partner, TAKE IT and be on your best behaviour, if $partner likes you then you have massively increased chances of making useful things happen later.
    - keepamovin 3y ago
      Yeah, that's a good point. But I think more often it's closer to 1 because (I guess this depends on our definition of 0 and 1 haha! :)) a) you get the benefit of their conceptual models for thinking about the codebase, which is hard won and highly useful, and b) you grok any practical pitfalls or things to remember when running, building, testing, that may be simple enough, but in the space of all possibilities are hard to come by without knowing them. So basically you get to go from: 0 - can do nothing at all; to 1 - being able to feel confident diving in and looking around, framed with the downloaded conceptual models, knowing how to hit the ground trotting, if not running. To me, 0.1 is more like you slugged it out for a couple hours poking around by yourself, and now you know a handful of confusing things with low confidence. Chatting to one who has been there, done that lets you have more confidence, and know more actionable stuff, which is highly useful. I suppose it depends on your conversation, listening and comprehension skills tho! Hahaha! :) But seriously not everybody learns well in that situation. I just happen to. I'd much rather talk it over with someone and absorb, than watch a video or read a tutorial. Finally -- haha! :) -- I guess there are some geeks to whose schedule the way is through their husband or whatevs haha! :)
- Joel_Mckay 3y ago
  I've always found discussing why former employees left a project incredibly enlightening. They will usually explain the reality behind the PR given they are no longer involved in the politics. Most importantly they will often tell you your best case future with a firm. Normally, employment agreements specifically restrict contact with former staff, or discussions of sensitive matters like compensation packages. C++ is like any other language, in that it will often take 3 times longer to understand something than re-implement the same. If you are lucky, than everything is a minimal API lib, and you get repetitive examples of the use cases... but the cooperative OSS breadcrumb model almost never happens in commercial shops... Legacy code bases can be hell to work with, as you end up with the responsibility for 14 years of IT kludges. Also, the opinions from entrenched lamers on what productivity means will be painful at first. Usually, with C++ it can become its own project specific language variant (STL or Boost may help wrangle the chaos). You have my sympathy, but no checklist can help with naive design inertia. Have a wonderful day. =)
  - keepamovin 3y ago
    Uh, yeah, that's a great idea, too! That's the big question. What happened to the previous team? Can give you org insights as well as code ones. Info on company strategy, priorities, work cadence. Actually a pretty good open ended conversation opener! Hahaha! :)
  - saagarjha 3y ago
    Note that depending on your jurisdiction discussion of compensation may be a right protected by law.
    - Joel_Mckay 3y ago
      Contract law has weird consequences in different places. Indeed, if the legal encumbrance is not legal, than its often unenforceable. Talking with your own lawyers before doing something silly is a good habit. ;-)
- mellutussa 3y ago
  > A one-off won't help much at all. Monumentally disagree. One-off session with a guy who knows the codebase inside out can save you days of research work. Plus telling you all about the problematic/historical areas.
  - Night_Thastus 3y ago
    I'm just stating my experience. A single day, if they still have access to the codebase might be able to clear up some top-level concepts. But the devil is in all the tiny details. What is this tiny correction factor that was added 20 years ago? Why was this value cut off to X decimals? Why didn't they just do Y here? Why do we override this default behavior? It's tens of thousands of tiny questions like that which you can't ask until you're there.
    - slingnow 3y ago
      I don't understand what you're saying. Clearly both types of meetings (one-off vs recurring) would be helpful. The one-off may save you days/weeks of research, but it seems like you're not satisfied with that unless you can answer every single minor question you might have across the entire codebase.
      - Night_Thastus 3y ago
        I'm saying that if you're maintaining a code base for years, a single day's explanations won't do much of anything. It's a drop in the bucket. It's not a bad thing, and it's certainly good to do, but it's not a solution to the problem.
        mellutussa 3y ago
        If your granularity for a task is measured in years then you have a much different and harder problem. Effectively everything becomes a "drop in the bucket".
        3y ago
raverbashing 3y ago
Easier said than done My step 0 would be: run it through an UML tool to get a class diagram and other diagrams. This will help you a lot. > Get the tests passing on your machine Tests? On a C++ codebase? I like your optimism, rs
- Joel_Mckay 3y ago
  No one has time to maintain the UML in production. You may luck out with auto-generated documentation, but few use these tools properly (javadoc or doxygen). =)
  - cratermoon 3y ago
    The GP said nothing about keeping and maintaining it, only generating it. Use it to understand the codebase, then archive it or throw it out.
    - Jtsummers 3y ago
      Exactly. You inherited 500k SLOC of C++ that grew together since 1985. You don't know the interconnections between the classes that have accumulated in that time. It was also developed by multiple teams, and likely had very different approaches to OO during these past nearly 40 years. The UML diagrams won't tell you everything, but they will tell you things like the inheritance hierarchy (if this was a 1990s C++ project it's probably pretty nasty), what classes are referenced by others via member variables, etc. This can be hugely informative when you want to transform a program into something saner.
      - Joel_Mckay 3y ago
        I always interpreted most polymorphism as sloppy context-specific state-machine embedding, and fundamentally an unmaintainable abomination from OOP paradigms. OO requires a lot of planning to get right (again, no shop will give your team time to do this properly), and in practice it usually degenerates into spiral development rather quickly (<2 years). Thus, 14 years later what you think you see in documentation may be completely different from the conditional recursive definition some clown left for your team (yes, it happens eventually...) 500k lines is not that bad if most of it is encapsulated libraries... =)
GuB-42 3y ago
I wouldn't make it the first step. If you do, you will probably waste their time more than anything. Try to work on it a little bit first, and once you get stuck in various places, now you can talk to the previous maintainers, it will be much more productive. They will also appreciate the effort.
- guhidalg 3y ago
  There’s a fine balance with no right or wrong answer. Previous maintainers will appreciate if you spent literally more than a second trying to understand before you reach out to them, but for your own sanity you should know when it’s time to stop and call for help.
- keepamovin 3y ago
  Yeah, that's fair enough. I guess since we're already zero-indexed maybe my -1 step is Prep. Hahaha! :)
- keepamovin 3y ago
  While this sounds good, it sort of assumes you're trying to solve some puzzle, and you're going to them for hints and answer. That's not the problem at hand tho: we're not asking them to solve some puzzle for us, we're just seeking understanding. Because what we're actually doing is building capability to be able to work on a wide range of problems on our own. And getting guided by people who already know there way around the codebase and know what everything does is going to get you there quicker than any other method (unless docs are truly excellent, which in most cases they're not). So, after reflecting on it more, I disagree. I think assuming you can poke around for yourself, and start to build up a picture of what things do, may end up giving you confident delusions, that could be then hard to unlearn, or at least blockers to further understanding. Better to go to the old guard with a blank slate mindset, and let them fill you in on the overview. Then go away and work on it, having that guidance in store, and then (if you were friendly enough in the first meet) come back for additional. That is what I think people would truly appreciate. Think about it: assume you were someone who generally had time to help people coming to you for assistance, would you not love to sit someone down and give them an in depth download of the big picture, and details overview, of this thing into which you poured great love and devotion (or at least, many hours, sweat and dollars?). I think you would. Anyway, it's a reminder to me that what often sounds right in the moment, and is easy to agree with, actually turns out to not be the best idea. I'm always eager to see another side, and empathize with someone else's view, but the lesson for me is: I often take that too far, and in doing so, forget what I originally came in with, forget my own frame, and forget what's true, so eager am I to see it from someone else's point of view. So that's a big lesson for me. Thanks for being part of it! Haha! :)
theamk 3y ago
Maybe do a quick look at codebase first so you can identify biggest WTF's and ask about them. After all, if you have inherited a codebase with no tests, with build process which fails every other time, with unknown dependency info, and which can only be built on a single server with severely outdated OS... are you sure the previous maintainer is a real wizard and all the problems are result of not enough time? Or are they a "wizard" who keep things broken for job security and/or because they don't want to learn new things?
- keepamovin 3y ago
  Yes! Good idea. Locking in at -1. Hahah! :)
- vaylian 3y ago
  Even if that person is not a great archwizard, they still have more experience in that project than you and you will probably learn some things that will make your life less miserable, because you will better understand what to expect and what kind of failed solutions have been tried before.
lelanthran 3y ago
> It's funny. My first step would be > 0. You reach out to the previous maintainers, visit them, buy them tea/beer and chat (eventually) about the codebase. Learned Wizards will teach you much. Have you ever tried that? This is legacy code. Even if the handover was yesterday, they cannot tell you about anything useful they did more than 6m in the past. And that's the best-case scenario. The common-case is "That's the way I got it when it was handed over to me" answer to every question you ask.
- mst 3y ago
  I have, and assuming your predecessor doesn't mind, you still get enough useful answers to make it worth it a lot of the time. Especially if you manage to get to just chatting about the project - at some point they'll almost certainly go "oh! while I remember," followed by the answer to a question you didn't realise you should've asked. The value is often in the commiseration rather than the interrogation, basically.
fransje26 3y ago
> You reach out to the previous maintainers, visit them I could have brought them flowers, and shared a moment of silence contemplating eternity. I don't know if it would significantly have helped understanding the code base though..
planede 3y ago
You mean the guys the company laid off last week?
- keepamovin 3y ago
  Ouch, yeah. I appreciate your topicality with this comment given the recent saga of tech layoffs. Much luck to you if you're in that experience right now!! Say you got fired form a S.Eng job at 350K yearly and some young grunt on 165K slid into your DMs and wanted to meet to chat. What would make you agree to that? I think it's unlikely, but perhaps if they reflected to you all the things you already thought were stupid about that company, and that you suffered with. You would want to help them as in their suffering, you could see your own, despite getting laid off. I think in that situation, there's a chance you might actually go over the codebase with them, in a conversation that mixed 1 part that, with 1 part self-commiserating and complaining/airing/venting about the org. What at first seems an unlikely pairing, I think, given the right "relational config" in moment could actually end up working pretty well. Seems there's plenty opportunities for such a coupling to have many fruitful outputs for both parties.
  - planede 3y ago
    > What would make you agree to that? Money. Charging the higher end of typical consulting rates. That's your competition. It's OK to want to help the young engineers, it doesn't mean that you shouldn't charge the company while you are at it. It would be foolish to do it for free, you effectively wouldn't do it for free even if you still worked there.
TrackerFF 3y ago
I was once tasked with deploying a piece of software on a closed network (military), to run on a old custom OS - it wasn't a huge program, around 50k lines of code. I did encounter a bunch of bugs and problems underway, and wanted to reach out to the devs that wrote it - as it was customer made for my employer. Welp, turns out it was written by one guy/contractor, and that he had passed away a couple of years earlier. At least in the defense industry you'll find these sort of things all the time. Lots of custom/one-off stuff, made for very specific systems. Especially on the hardware side it is not uncommon that the engineers that made the equipment are either long gone or retired.
- keepamovin 3y ago
  Welp, you might have needed to consult a seance for that one. Interesting point about the "author expiry" window. I was thinking about that today regarding something else: Let's say in 20 years time, no database code has been updated for the last 20 years. And all the people who worked on it, can't remember anything about it. Yet, it still works. That means that everyone who uses that database everyday, doesn't know how it works. They believe that it works, this belief is widespread. And the database providing results to queries, is a real thing. And it does work -- but nobody knows how. This is common. I don't know in any detail how the MacBook I use works. But it does. I don't know how many things I use actually work. But they do work. It seems the only difference, in the world of things that "work", and which most people who use them do not understand how they work, is that there are two classes of things: those things for which there is a widespread belief that they do work; and those things for which the belief that they work, is not widespread. But in either case, they work.
  - TrackerFF 3y ago
    Even more common in the world of industrial automation. Lots of old early-gen PLCs from the 70s/80s still ticking, with no documentation and the techs/engineers/companies long gone. We worked on one such PLC, around 3 decades old at the point, and it came down to probing I/O, reverse engineering the functionality. But at some point, if there hasn't been enough legacy support, there comes a time where people just have to bite the bullet and re-build a system from the ground up - and integrate it in parallel with the old system running, until it can be removed completely. Too bad many of the old and forgotten systems are still running and integral, so they get put inside a glass cage with "DON'T TOUCH!" warning sticker.

Night_Thastus 3y ago

IME, this only works if you can get regular help from them. A one-off won't help much at all.

keepamovin 3y ago
Yeah you need to cultivate those relationships. But with a willing partner that first session will take you from 0 to 1 :)
- mst 3y ago
  A lot of the time it takes you from 0 to 0.1, but (a) every little helps (b) if you take them out for lunch or a post-work beer or whatever it can build a relationship where you can ask follow up questions via email. Ideal is if they have a life such that something morally equivalent to "how about we meet up and I'll pay for the food/beer" is a viable thing to suggest later. Oh, and always remember - the way to a geek's schedule is often through their wife. If you get a chance to meet their partner, TAKE IT and be on your best behaviour, if $partner likes you then you have massively increased chances of making useful things happen later.
  - keepamovin 3y ago
    Yeah, that's a good point. But I think more often it's closer to 1 because (I guess this depends on our definition of 0 and 1 haha! :)) a) you get the benefit of their conceptual models for thinking about the codebase, which is hard won and highly useful, and b) you grok any practical pitfalls or things to remember when running, building, testing, that may be simple enough, but in the space of all possibilities are hard to come by without knowing them. So basically you get to go from: 0 - can do nothing at all; to 1 - being able to feel confident diving in and looking around, framed with the downloaded conceptual models, knowing how to hit the ground trotting, if not running. To me, 0.1 is more like you slugged it out for a couple hours poking around by yourself, and now you know a handful of confusing things with low confidence. Chatting to one who has been there, done that lets you have more confidence, and know more actionable stuff, which is highly useful. I suppose it depends on your conversation, listening and comprehension skills tho! Hahaha! :) But seriously not everybody learns well in that situation. I just happen to. I'd much rather talk it over with someone and absorb, than watch a video or read a tutorial. Finally -- haha! :) -- I guess there are some geeks to whose schedule the way is through their husband or whatevs haha! :)
Joel_Mckay 3y ago
I've always found discussing why former employees left a project incredibly enlightening. They will usually explain the reality behind the PR given they are no longer involved in the politics. Most importantly they will often tell you your best case future with a firm. Normally, employment agreements specifically restrict contact with former staff, or discussions of sensitive matters like compensation packages. C++ is like any other language, in that it will often take 3 times longer to understand something than re-implement the same. If you are lucky, than everything is a minimal API lib, and you get repetitive examples of the use cases... but the cooperative OSS breadcrumb model almost never happens in commercial shops... Legacy code bases can be hell to work with, as you end up with the responsibility for 14 years of IT kludges. Also, the opinions from entrenched lamers on what productivity means will be painful at first. Usually, with C++ it can become its own project specific language variant (STL or Boost may help wrangle the chaos). You have my sympathy, but no checklist can help with naive design inertia. Have a wonderful day. =)
- keepamovin 3y ago
  Uh, yeah, that's a great idea, too! That's the big question. What happened to the previous team? Can give you org insights as well as code ones. Info on company strategy, priorities, work cadence. Actually a pretty good open ended conversation opener! Hahaha! :)
- saagarjha 3y ago
  Note that depending on your jurisdiction discussion of compensation may be a right protected by law.
  - Joel_Mckay 3y ago
    Contract law has weird consequences in different places. Indeed, if the legal encumbrance is not legal, than its often unenforceable. Talking with your own lawyers before doing something silly is a good habit. ;-)
mellutussa 3y ago
> A one-off won't help much at all. Monumentally disagree. One-off session with a guy who knows the codebase inside out can save you days of research work. Plus telling you all about the problematic/historical areas.
- Night_Thastus 3y ago
  I'm just stating my experience. A single day, if they still have access to the codebase might be able to clear up some top-level concepts. But the devil is in all the tiny details. What is this tiny correction factor that was added 20 years ago? Why was this value cut off to X decimals? Why didn't they just do Y here? Why do we override this default behavior? It's tens of thousands of tiny questions like that which you can't ask until you're there.
  - slingnow 3y ago
    I don't understand what you're saying. Clearly both types of meetings (one-off vs recurring) would be helpful. The one-off may save you days/weeks of research, but it seems like you're not satisfied with that unless you can answer every single minor question you might have across the entire codebase.
    - Night_Thastus 3y ago
      I'm saying that if you're maintaining a code base for years, a single day's explanations won't do much of anything. It's a drop in the bucket. It's not a bad thing, and it's certainly good to do, but it's not a solution to the problem.
      - mellutussa 3y ago
        If your granularity for a task is measured in years then you have a much different and harder problem. Effectively everything becomes a "drop in the bucket".
        3y ago

raverbashing 3y ago

Easier said than done My step 0 would be: run it through an UML tool to get a class diagram and other diagrams. This will help you a lot. > Get the tests passing on your machine Tests? On a C++ codebase? I like your optimism, rs

Joel_Mckay 3y ago
No one has time to maintain the UML in production. You may luck out with auto-generated documentation, but few use these tools properly (javadoc or doxygen). =)
- cratermoon 3y ago
  The GP said nothing about keeping and maintaining it, only generating it. Use it to understand the codebase, then archive it or throw it out.
  - Jtsummers 3y ago
    Exactly. You inherited 500k SLOC of C++ that grew together since 1985. You don't know the interconnections between the classes that have accumulated in that time. It was also developed by multiple teams, and likely had very different approaches to OO during these past nearly 40 years. The UML diagrams won't tell you everything, but they will tell you things like the inheritance hierarchy (if this was a 1990s C++ project it's probably pretty nasty), what classes are referenced by others via member variables, etc. This can be hugely informative when you want to transform a program into something saner.
    - Joel_Mckay 3y ago
      I always interpreted most polymorphism as sloppy context-specific state-machine embedding, and fundamentally an unmaintainable abomination from OOP paradigms. OO requires a lot of planning to get right (again, no shop will give your team time to do this properly), and in practice it usually degenerates into spiral development rather quickly (<2 years). Thus, 14 years later what you think you see in documentation may be completely different from the conditional recursive definition some clown left for your team (yes, it happens eventually...) 500k lines is not that bad if most of it is encapsulated libraries... =)

GuB-42 3y ago

I wouldn't make it the first step. If you do, you will probably waste their time more than anything. Try to work on it a little bit first, and once you get stuck in various places, now you can talk to the previous maintainers, it will be much more productive. They will also appreciate the effort.

guhidalg 3y ago
There’s a fine balance with no right or wrong answer. Previous maintainers will appreciate if you spent literally more than a second trying to understand before you reach out to them, but for your own sanity you should know when it’s time to stop and call for help.
keepamovin 3y ago
Yeah, that's fair enough. I guess since we're already zero-indexed maybe my -1 step is Prep. Hahaha! :)
keepamovin 3y ago
While this sounds good, it sort of assumes you're trying to solve some puzzle, and you're going to them for hints and answer. That's not the problem at hand tho: we're not asking them to solve some puzzle for us, we're just seeking understanding. Because what we're actually doing is building capability to be able to work on a wide range of problems on our own. And getting guided by people who already know there way around the codebase and know what everything does is going to get you there quicker than any other method (unless docs are truly excellent, which in most cases they're not). So, after reflecting on it more, I disagree. I think assuming you can poke around for yourself, and start to build up a picture of what things do, may end up giving you confident delusions, that could be then hard to unlearn, or at least blockers to further understanding. Better to go to the old guard with a blank slate mindset, and let them fill you in on the overview. Then go away and work on it, having that guidance in store, and then (if you were friendly enough in the first meet) come back for additional. That is what I think people would truly appreciate. Think about it: assume you were someone who generally had time to help people coming to you for assistance, would you not love to sit someone down and give them an in depth download of the big picture, and details overview, of this thing into which you poured great love and devotion (or at least, many hours, sweat and dollars?). I think you would. Anyway, it's a reminder to me that what often sounds right in the moment, and is easy to agree with, actually turns out to not be the best idea. I'm always eager to see another side, and empathize with someone else's view, but the lesson for me is: I often take that too far, and in doing so, forget what I originally came in with, forget my own frame, and forget what's true, so eager am I to see it from someone else's point of view. So that's a big lesson for me. Thanks for being part of it! Haha! :)

theamk 3y ago

Maybe do a quick look at codebase first so you can identify biggest WTF's and ask about them. After all, if you have inherited a codebase with no tests, with build process which fails every other time, with unknown dependency info, and which can only be built on a single server with severely outdated OS... are you sure the previous maintainer is a real wizard and all the problems are result of not enough time? Or are they a "wizard" who keep things broken for job security and/or because they don't want to learn new things?

keepamovin 3y ago
Yes! Good idea. Locking in at -1. Hahah! :)
vaylian 3y ago
Even if that person is not a great archwizard, they still have more experience in that project than you and you will probably learn some things that will make your life less miserable, because you will better understand what to expect and what kind of failed solutions have been tried before.

lelanthran 3y ago

> It's funny. My first step would be > 0. You reach out to the previous maintainers, visit them, buy them tea/beer and chat (eventually) about the codebase. Learned Wizards will teach you much. Have you ever tried that? This is legacy code. Even if the handover was yesterday, they cannot tell you about anything useful they did more than 6m in the past. And that's the best-case scenario. The common-case is "That's the way I got it when it was handed over to me" answer to every question you ask.

mst 3y ago
I have, and assuming your predecessor doesn't mind, you still get enough useful answers to make it worth it a lot of the time. Especially if you manage to get to just chatting about the project - at some point they'll almost certainly go "oh! while I remember," followed by the answer to a question you didn't realise you should've asked. The value is often in the commiseration rather than the interrogation, basically.

fransje26 3y ago

> You reach out to the previous maintainers, visit them I could have brought them flowers, and shared a moment of silence contemplating eternity. I don't know if it would significantly have helped understanding the code base though..

planede 3y ago

You mean the guys the company laid off last week?

keepamovin 3y ago
Ouch, yeah. I appreciate your topicality with this comment given the recent saga of tech layoffs. Much luck to you if you're in that experience right now!! Say you got fired form a S.Eng job at 350K yearly and some young grunt on 165K slid into your DMs and wanted to meet to chat. What would make you agree to that? I think it's unlikely, but perhaps if they reflected to you all the things you already thought were stupid about that company, and that you suffered with. You would want to help them as in their suffering, you could see your own, despite getting laid off. I think in that situation, there's a chance you might actually go over the codebase with them, in a conversation that mixed 1 part that, with 1 part self-commiserating and complaining/airing/venting about the org. What at first seems an unlikely pairing, I think, given the right "relational config" in moment could actually end up working pretty well. Seems there's plenty opportunities for such a coupling to have many fruitful outputs for both parties.
- planede 3y ago
  > What would make you agree to that? Money. Charging the higher end of typical consulting rates. That's your competition. It's OK to want to help the young engineers, it doesn't mean that you shouldn't charge the company while you are at it. It would be foolish to do it for free, you effectively wouldn't do it for free even if you still worked there.

TrackerFF 3y ago

I was once tasked with deploying a piece of software on a closed network (military), to run on a old custom OS - it wasn't a huge program, around 50k lines of code. I did encounter a bunch of bugs and problems underway, and wanted to reach out to the devs that wrote it - as it was customer made for my employer. Welp, turns out it was written by one guy/contractor, and that he had passed away a couple of years earlier. At least in the defense industry you'll find these sort of things all the time. Lots of custom/one-off stuff, made for very specific systems. Especially on the hardware side it is not uncommon that the engineers that made the equipment are either long gone or retired.

keepamovin 3y ago
Welp, you might have needed to consult a seance for that one. Interesting point about the "author expiry" window. I was thinking about that today regarding something else: Let's say in 20 years time, no database code has been updated for the last 20 years. And all the people who worked on it, can't remember anything about it. Yet, it still works. That means that everyone who uses that database everyday, doesn't know how it works. They believe that it works, this belief is widespread. And the database providing results to queries, is a real thing. And it does work -- but nobody knows how. This is common. I don't know in any detail how the MacBook I use works. But it does. I don't know how many things I use actually work. But they do work. It seems the only difference, in the world of things that "work", and which most people who use them do not understand how they work, is that there are two classes of things: those things for which there is a widespread belief that they do work; and those things for which the belief that they work, is not widespread. But in either case, they work.
- TrackerFF 3y ago
  Even more common in the world of industrial automation. Lots of old early-gen PLCs from the 70s/80s still ticking, with no documentation and the techs/engineers/companies long gone. We worked on one such PLC, around 3 decades old at the point, and it came down to probing I/O, reverse engineering the functionality. But at some point, if there hasn't been enough legacy support, there comes a time where people just have to bite the bullet and re-build a system from the ground up - and integrate it in parallel with the old system running, until it can be removed completely. Too bad many of the old and forgotten systems are still running and integral, so they get put inside a glass cage with "DON'T TOUCH!" warning sticker.