- 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"
- a programmer/scripter who can develop the management reports on-demand
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
> a text file (with an undefined character encoding)
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).
> an undefined structure for the header of the file
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.
> a rule that status must be 'open' or 'closed' in every human head
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.
> a revision control system which dates changes
No need to wonder how to enforce proper date control. And less code
> 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"
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.
> a programmer/scripter who can develop the management reports on-demand
It was 1986. If you have a computer on site, you also have a programmer available.
---
So you got a working solution without investing too much resources solving subproblems, some of which are not even important.
tl;dr The author [0] describes a simple ticketing system that his very busy coworker, Peter Högfeldt, created in 1986. Basically, it checked in numbered files to their version control (CVS, at the time) that could produce reports with grep. This system's simplicity lead to its longevity, as people could learn it easily and trust that its bugs had been ironed out long ago. This is in contrast to some OS software that tries to be everything to everyone and changes all the time [1].
I find this a helpful example. When I've heard the unix philosophy in the past, I didn't feel super convinced. Like, sure tar can do one thing, because it is a library (ignore that it can use gzip). But, where do you draw the line with a program like gnucash (financial tracking software) ? The core of the domain will involve keeping a ledger of transactions and converting them to relevant units. But, typing credit card charges in by hand is tedious [2], the kind of tedious that a computer should be good at. I would much rather that the program connect to my bank [3], to get the transactions directly.
Though see the Plain Text Accounting[0] movement for something maybe more unixy than Gnucash. I download .csv files from my bank and credit card issuers and import to hledger[1]. hledger has its own rules engine for filtering/transforming imported entries, but you could also preprocess the files using any unix tool before importing if you needed to.
But which part is the minimal ticketing system?
- a text file (with an undefined character encoding)
- an undefined structure for the header of the file
- a rule that status must be 'open' or 'closed' in every human head
- a revision control system which dates changes
- a filesystem, terminal, multi-user OS, shell (piping, globbing, environment variables), grep, wc
- 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"
- a programmer/scripter who can develop the management reports on-demand
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
> a text file (with an undefined character encoding)
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).
> an undefined structure for the header of the file
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.
> a rule that status must be 'open' or 'closed' in every human head
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.
> a revision control system which dates changes
No need to wonder how to enforce proper date control. And less code
> a filesystem, terminal, multi-user OS, shell (piping, globbing, environment variables), grep, wc
Comes with UNIX,
> 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"
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.
> a programmer/scripter who can develop the management reports on-demand
It was 1986. If you have a computer on site, you also have a programmer available.
---
So you got a working solution without investing too much resources solving subproblems, some of which are not even important.
Nice, this is still used today? I wish the construction industry had a standardized issue reporting system like this.
tl;dr The author [0] describes a simple ticketing system that his very busy coworker, Peter Högfeldt, created in 1986. Basically, it checked in numbered files to their version control (CVS, at the time) that could produce reports with grep. This system's simplicity lead to its longevity, as people could learn it easily and trust that its bugs had been ironed out long ago. This is in contrast to some OS software that tries to be everything to everyone and changes all the time [1].
[0] https://en.wikipedia.org/wiki/Joe_Armstrong_(programmer) Joe Armstrong, of Erlang fame, so his blog posts have been discussed in the past.
[1] https://ntdotdev.wordpress.com/2023/01/01/state-of-the-windo...
I find this a helpful example. When I've heard the unix philosophy in the past, I didn't feel super convinced. Like, sure tar can do one thing, because it is a library (ignore that it can use gzip). But, where do you draw the line with a program like gnucash (financial tracking software) ? The core of the domain will involve keeping a ledger of transactions and converting them to relevant units. But, typing credit card charges in by hand is tedious [2], the kind of tedious that a computer should be good at. I would much rather that the program connect to my bank [3], to get the transactions directly.
[2] https://utcc.utoronto.ca/~cks/space/blog/sysadmin/Inventorie...
[3] https://beanhub.io/blog/2024/06/24/introduction-of-beanhub-c...
Though see the Plain Text Accounting[0] movement for something maybe more unixy than Gnucash. I download .csv files from my bank and credit card issuers and import to hledger[1]. hledger has its own rules engine for filtering/transforming imported entries, but you could also preprocess the files using any unix tool before importing if you needed to.
0: https://plaintextaccounting.org/
1: https://hledger.org/