Hacker News Reader

Comment by contravariant | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

Are you confusing software dependencies for the semantics of a running program?

If I understand your point correctly, software dependencies are absolutely part of a running program.

It's exceedingly rare that you would not be able to figure it out given the source code. The real question is whether you have the time.

I think if a project was that important, the people who needed something patched would be able to get it together even if the original maintainer went missing.

The original analogy to the challenges of knowledge transfer isn't totally applicable. Knowledge transfer is important to organizations because figuring everything out all over again would be costly, not because it would be impossible.

why does coding have to do with opinions and such? coding is about code. pure logic. fuck opinion. useless as a metric, as a standard.

None of us are coders as far as I know, I don't think that's a real job title. They call us programmers or developers or engineers.

We solve problems with code, or by finding ways to avoid writing code.

We translate vague requirements into things a computer can handle, or we translate between computer languages, because any spec that was complete would just be the program. That's why they keep us. The computers can do pure logic on their own.

Opinion is very much a part of it because pure logic is just a useless pile of text unless it has something to do with the real world, which is full of opinions.

Even inside the program itself, we aren't dealing with logic. Languages are designed for human minds, and compilers are meant to catch mistakes people make. Libraries are often chosen for all kinds of perfectly good nontechnical reasons, like "That one is actually maintained" or "Everyone already knows this" or "People seem to like this" or "That seems like it won't be a thing in 3 years".

As long as you are relying on the software, what you do care about is what it does today, which you get from the source.

You certainly care about what it will do tomorrow too (so you can keep up, or avoid having it break stuff for you), but if it goes unmaintained, you don't have to worry about that since it does the job for you.

OTOH, I've been on projects where a dependency was chosen on the promise of what they will do in the future. That future never materialized, so we were left with a bunch of unfinished dependency code, maintained a bunch of components ourselves etc — it was a mess, in short. So I never rely on promises, only on what's there today.

Very much so. I've spent a lot of time trying to decipher code and the biggest questions are usually "why is it doing this" and "what's this large piece of code indended to do".

Reverse-engineering all that can be an utter nightmare even with tests. I suggest that people who disagree consider, for example, the word "reverse-engineer" as in how they might reverse-engineer a car.

Usually you have this kind of problem when it's NOT producing desired results and the problem is how to make it do something that's needed without affecting some set of usecases that you don't understand yet.

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.

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.

Reply on news.ycombinator.com