5 ms·

The annoying thing about software is that we still haven't quite gotten the transfer of knowledge working to the point that you can communicate all knowledge ab

The annoying thing about software is that we still haven't quite gotten the transfer of knowledge working to the point that you can communicate all knowledge about a piece of software purely through code (and no, being able to emulate all behaviour is not the same, otherwise decompiling wouldn't be a thing). What this means is that for most software an essential part of that software consists of knowledge that needs to be kept alive. The only proof people can have of this is activity surrounding the project. This puts us in the uncomfortable position of having to designate someone as the 'keeper of all knowledge' surrounding a project if it is to be sustained, and failing to do so will result in knowledge being irrevocably lost.

jongjong 4y ago
I think it depends heavily on the coding style. In many corporate environments, developers tend to obfuscate or over-engineer or they will tend to introduce too much complexity into the project.
eternityforest 4y ago
If you have source, you can figure it out. If there's something clever in source that isn't obvious, that's either a problem, or a well documented exception to the rule. If your whole entire source code is so innovative that you can't immediately understand it, there might be trouble, but so much code is or can be pretty boring. At most, changing something will make a bug that's not really in the spec but is something everyone wants and relies on, but isn't immediately obvious, then you'll have to fix it. The trouble is that if knowledge is lost, people will probably not bother to figure it out, and starting fresh might be more appealing. The bigger issue especially in open source is that if there's no activity, there might not be any in the future. It could be abandoned for 10 years and perfectly fine, until a change is needed, and even if the change is easy and the knowledge is there, it might not happen if nobody cares anymore, and you'll have to fork it yourself, so maybe you choose the actively maintained thing even if it's less complete or more complex or ugly to use.
- thristian 4y ago
  Even if you have source, you can't necessarily figure it out. Sure, you can figure out what the program does, but you can't know precisely what the program was intended to do, or how closely the current version matches that eventual goal. Sure, you might have the specification that the original developer was given, but every developer brings their own opinions and hard-won experience to a project. Just because the specification says "outgoing messages are sent to a queue" and the program links with ZeroMQ, doesn't tell you whether that's a design goal or a temporary stop-gap proof-of-concept. Maybe the program is structured so it can use an email queue for distributed operation. Maybe the program is designed to be linked into a larger system and just push message structs onto an in-memory vector.
  - skydhash 4y ago
    I think a better way to go about it is to state your own goals. If you want it to bridge it to ZeroMQ, you can evaluate the program and see if the way it is coded fits you. If you want another service, you evaluate how much work to retrofit it. As longs as you expect decades out of your software, you should prepare to own all your dependencies. The intention of the original developer does not matter that much.
  - eternityforest 4y ago
    What a program does at the moment is exactly what it should do, unless there's a bug report filed, or the current developers want it to do something else. Whatever it was originally meant to do is probably either obsolete, or well known to all users, if it's been so long the original devs left. If it's got ZeroMQ, and has for 5 years, one can probably assume someone will be upset if it suddenly does not have ZeroMQ. Regardless of intent, for practical purposes, if people are using it, they probably want that to stay around until you do an orderly transition to some other thing.
    - capn_duck 4y ago
      Are you confusing software dependencies for the semantics of a running program?
toasted-subs 4y ago
Software would be a point in space. There are multiple types of documentation which can either justify why the point would be where it is, or what direction it should move in.

jongjong 4y ago

I think it depends heavily on the coding style. In many corporate environments, developers tend to obfuscate or over-engineer or they will tend to introduce too much complexity into the project.

eternityforest 4y ago

If you have source, you can figure it out. If there's something clever in source that isn't obvious, that's either a problem, or a well documented exception to the rule. If your whole entire source code is so innovative that you can't immediately understand it, there might be trouble, but so much code is or can be pretty boring. At most, changing something will make a bug that's not really in the spec but is something everyone wants and relies on, but isn't immediately obvious, then you'll have to fix it. The trouble is that if knowledge is lost, people will probably not bother to figure it out, and starting fresh might be more appealing. The bigger issue especially in open source is that if there's no activity, there might not be any in the future. It could be abandoned for 10 years and perfectly fine, until a change is needed, and even if the change is easy and the knowledge is there, it might not happen if nobody cares anymore, and you'll have to fork it yourself, so maybe you choose the actively maintained thing even if it's less complete or more complex or ugly to use.

thristian 4y ago
Even if you have source, you can't necessarily figure it out. Sure, you can figure out what the program does, but you can't know precisely what the program was intended to do, or how closely the current version matches that eventual goal. Sure, you might have the specification that the original developer was given, but every developer brings their own opinions and hard-won experience to a project. Just because the specification says "outgoing messages are sent to a queue" and the program links with ZeroMQ, doesn't tell you whether that's a design goal or a temporary stop-gap proof-of-concept. Maybe the program is structured so it can use an email queue for distributed operation. Maybe the program is designed to be linked into a larger system and just push message structs onto an in-memory vector.
- skydhash 4y ago
  I think a better way to go about it is to state your own goals. If you want it to bridge it to ZeroMQ, you can evaluate the program and see if the way it is coded fits you. If you want another service, you evaluate how much work to retrofit it. As longs as you expect decades out of your software, you should prepare to own all your dependencies. The intention of the original developer does not matter that much.
- eternityforest 4y ago
  What a program does at the moment is exactly what it should do, unless there's a bug report filed, or the current developers want it to do something else. Whatever it was originally meant to do is probably either obsolete, or well known to all users, if it's been so long the original devs left. If it's got ZeroMQ, and has for 5 years, one can probably assume someone will be upset if it suddenly does not have ZeroMQ. Regardless of intent, for practical purposes, if people are using it, they probably want that to stay around until you do an orderly transition to some other thing.
  - capn_duck 4y ago
    Are you confusing software dependencies for the semantics of a running program?

toasted-subs 4y ago

Software would be a point in space. There are multiple types of documentation which can either justify why the point would be where it is, or what direction it should move in.