- 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
> 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.
Takeaways :
- On writing - make your point early and get away from the reader
- The simplicity is the ultimate form of sophistication - Steve Jobs
- Certain programs just works, not because they are well engineered but they didn't add unnecessary features
- In fact, I have a small open source program built on this philosophy, it Just does one thing that's it.
[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...
