It's minimally viable, which means it does what people needs now without costing too much in resources. I'm not Joe (I wasn't even born at that time), but<p>> a text file (with an undefined character encoding)<p>Most team kinda have the same system to work from, so character encodings doesn't matter much (and people who deviates from the norm know how to handle such things).<p>> an undefined structure for the header of the file<p>That's pretty much YAGNI. By the time you get to this point, you could probably switch to a DBMS and import the old data.<p>> a rule that status must be 'open' or 'closed' in every human head<p>A lot of rules, even today, are encoded in human head. In the ticketing systems at $WORK, each team has a different set of fields with different semantics for the status field. And there's a global repo. You can easily enforce that new addition don't have any other value.<p>> a revision control system which dates changes<p>No need to wonder how to enforce proper date control. And less code<p>> a filesystem, terminal, multi-user OS, shell (piping, globbing, environment variables), grep, wc<p>Comes with UNIX,<p>> an out of band way to request and obtain permission to change the owner, possibly a high-trust environment with no arguing "you agreed" "no I didn't"<p>The owner of the ticket? Why can't it be a new update to the file? It's version controlled. And the import to the global repo (which I think is the source of truth) can be monitored and constraints enforced.<p>> a programmer/scripter who can develop the management reports on-demand<p>It was 1986. If you have a computer on site, you also have a programmer available.<p>---<p>So you got a working solution without investing too much resources solving subproblems, some of which are not even important.