4 ms·

Minimal Viable Programs – Joe Armstrong – Erlang and Other Stuff

sodapopcan 5y ago
> If you want a job done find the busiest person you know and give them an extra job. This is because the reason they are busy is that lot's of people want them to do things because they are good at doing things and that's why they are busy. Love Joe Armstrong.
- nickcox 5y ago
  I've always heard this as, 'If you want something done, ask a busy person'. https://quoteinvestigator.com/2018/01/30/busy/ https://quoteinvestigator.com/2018/01/30/busy/
- mbrodersen 5y ago
  Or perhaps find the most competent person who isn’t busy? Incompetent people tend to be busy all the time because they don’t know how to work effectively. A bad developer will add as many bugs as new features and will therefore be busy all the time, always falling behind. A great developer will introduce very few new bugs and can therefore easily add new features, not falling behind.
dpeck 5y ago
Gone too soon. I hope that Joe’s influence continues to expand outside of the erlang community over time. His thoughts, writings, and presentations have a lot of value for almost anyone in computing. Much of it advocating for “human scale” software that is reasonable to work with from a developer and end user perspective.
- Turing_Machine 5y ago
  Yes, he is sorely missed. I recommend his videos to those who haven't seen them.
imachine1980_ 5y ago
"Good examples are Dropbox and Twitter. Dropbox just works. Twitter has a no fuss 140 character"
- abrookewood 5y ago
  Well, maybe once upon a time. Now DropBox won't stop shoving new and unnecessary features down my throat.
  - hydrox24 5y ago
    If you're looking for an open-source replacement, I have been really impressed with Syncthing. It is decentralised (and directly device-to-device), but if you can afford the space on your phone or an always-on computer at home, it is basically a drop-in replacement for Dropbox. It only worries about syncing files. Nothing else. https://syncthing.net/ https://syncthing.net/
    - microtonal 5y ago
      Or if you want Dropbox, because you need it for work or because it makes it's easier to share with family and friends, there is an awesome open source Dropbox client: https://maestral.app https://maestral.app I have been running it for months now without any issues.
      - abrookewood 5y ago
        Thanks for that - looks quite promising.
Jtsummers 5y ago
Two prior discussions with comments: https://news.ycombinator.com/item?id=21434844 https://news.ycombinator.com/item?id=21434844 - Nov 3, 2019 (72 comments) https://news.ycombinator.com/item?id=10159545 https://news.ycombinator.com/item?id=10159545 - Sep 2, 2015 (11 comments)
jacquesm 5y ago
If you haven't read it yet, please read Joe Armstrong's thesis: https://erlang.org/download/armstrong_thesis_2003.pdf https://erlang.org/download/armstrong_thesis_2003.pdf It is just as relevant today as when it was written.
alkonaut 5y ago
> This file was also checked into a global CVS archive that all project members had access to. Today one might use GIT or SVN but any revision control system would do. Having locally created sequential ID's seems...strange. Or you simply have so few people creating ID's (and committing them so quickly) that it's not an issue. There are tons of ways of resolving this (such as author-prefixed ids "joe-23"). But simply calling it ticket++ in a global shared directory seems it could become a source of frustration and honestly a pretty inelegant solution to the problem. He mentions "doing one thing and doing it well" and being a "minimum viable program". One could argue that doing ONE thing reasonably when it comes to creating database records, is allowing me to create one without a conflicting ID. If the new_ticket command is actually immediately creating the entry in the central repository, retrying until it successfully allocates the next ID, then it works I suppose.
- tpoacher 5y ago
  Having made a similar project (see comment above: https://news.ycombinator.com/item?id=29965597 https://news.ycombinator.com/item?id=29965597 ) there's a (predictable? unexpected?) benefit to keeping a numerical index. It forces the ticket opener to commit as soon as possible, or risk having to re-index their tickets due to conflicts. This means that in any multi-member project, it encourages users to first check that a similar/duplicate ticket has not already made it into the repository in the meantime, and commit their tickets and make them visible to all other users with an accompanyign commit (and any notification-hooks that this entails) as soon as possible. Obviously you could also have a commit hook which reindexes tickets automatically, yes, but the focus here is all about simplicity and hackability first - and I think a behavioural solution is probably better than an automated one in this case anyway.
- bachmeier 5y ago
  > Or you simply have so few people creating ID's (and committing them so quickly) that it's not an issue. Rule #1 of minimum viable programs is to solve the problems you have rather than as something (number of users in this case) goes to infinity. If you're working with software developers and they can't trivially resolve a merge conflict of this nature, perhaps they are not the best at their craft.
tpoacher 5y ago
I created something similar when I had to work in an extremely resource-constrained project (we could only work by ssh'ing to a server with no graphical utilities, and no internet access other than ssh). It has worked like a charm, and I would find it difficult to go back to anything else for ticket management now. I use this for 'in-project tickets/milestones' and leave stuff like github issues for 'external' issues by users. Here it is on github for anyone who's interested: https://github.com/tpapastylianou/bashtickets https://github.com/tpapastylianou/bashtickets My tool is slightly less minimal than the one in the article, but essentially the same philosophy. Everything is a local file following a simple but fixed template, so that they can be grepped / manipulated if necessary. It plays very well with versioning, and supports milestones and 'advanced queries' as pre-made scripts. Obviously, since the tickets/milestones are simple text, it should be fairly straightforward to write your own queries if you know a bit of bash (or any other language you prefer, obviously). In fact, this little system has worked so well, that I have recently been trying to convert it to a nice, portable, "command-based" tool, i.e. the way git works; bashtickets init (or just bt init) initialises a ticket repository, bt new ticket creates a new ticket, bt list lists open/closed tickets, or active/completed milestones etc. There's nothing wrong with the original, of course, except for the fact that it's a bit ugly to have a bag of scripts in each ticket repository you want to manage. A command-based interface simply makes it look a bit more 'modern', and clean, putting any pre-made scripts and 'template' files out of sight for peace of mind. This is still very much under development, but please see the "commandbased" branch if interested [1]. I'd be very open to feedback :) [0] https://github.com/tpapastylianou/bashtickets [1] https://github.com/tpapastylianou/bashtickets/tree/commandbased
solididiot 5y ago
What kind of blog is that? I mean if you navigate to the index https://joearms.github.io/index.html#Index https://joearms.github.io/index.html#Index it says that this is actually a Quine.
- CRConrad 5y ago
  Yeah, from his WP link quines are, among other descriptions, "self-replicating programs". And in the same blog header he also says it's a TiddlyWiki. That's one of many kinds of TinyWikis, and a rather interesting one in that it's self-contained: The entire source code for its Wikifying is contained as JavaScript within the actual HTML page itself. I guess that's what he means; TiddlyWiki pages are kind of "self-replicating" and therefore kind of quines.
bertman 5y ago
>Twitter has a no fuss 140 character tweet box. Simple, easy to understand and minimalist. Sigh, good old times... Maybe add 2014 to the title.

> If you want a job done find the busiest person you know and give them an extra job. This is because the reason they are busy is that lot's of people want them to do things because they are good at doing things and that's why they are busy. Love Joe Armstrong.

nickcox 5y ago
I've always heard this as, 'If you want something done, ask a busy person'. https://quoteinvestigator.com/2018/01/30/busy/ https://quoteinvestigator.com/2018/01/30/busy/
mbrodersen 5y ago
Or perhaps find the most competent person who isn’t busy? Incompetent people tend to be busy all the time because they don’t know how to work effectively. A bad developer will add as many bugs as new features and will therefore be busy all the time, always falling behind. A great developer will introduce very few new bugs and can therefore easily add new features, not falling behind.

dpeck 5y ago

Gone too soon. I hope that Joe’s influence continues to expand outside of the erlang community over time. His thoughts, writings, and presentations have a lot of value for almost anyone in computing. Much of it advocating for “human scale” software that is reasonable to work with from a developer and end user perspective.

Turing_Machine 5y ago
Yes, he is sorely missed. I recommend his videos to those who haven't seen them.

imachine1980_ 5y ago

"Good examples are Dropbox and Twitter. Dropbox just works. Twitter has a no fuss 140 character"

abrookewood 5y ago
Well, maybe once upon a time. Now DropBox won't stop shoving new and unnecessary features down my throat.
- hydrox24 5y ago
  If you're looking for an open-source replacement, I have been really impressed with Syncthing. It is decentralised (and directly device-to-device), but if you can afford the space on your phone or an always-on computer at home, it is basically a drop-in replacement for Dropbox. It only worries about syncing files. Nothing else. https://syncthing.net/ https://syncthing.net/
  - microtonal 5y ago
    Or if you want Dropbox, because you need it for work or because it makes it's easier to share with family and friends, there is an awesome open source Dropbox client: https://maestral.app https://maestral.app I have been running it for months now without any issues.
    - abrookewood 5y ago
      Thanks for that - looks quite promising.

Jtsummers 5y ago

Two prior discussions with comments: https://news.ycombinator.com/item?id=21434844 https://news.ycombinator.com/item?id=21434844 - Nov 3, 2019 (72 comments) https://news.ycombinator.com/item?id=10159545 https://news.ycombinator.com/item?id=10159545 - Sep 2, 2015 (11 comments)

jacquesm 5y ago

If you haven't read it yet, please read Joe Armstrong's thesis: https://erlang.org/download/armstrong_thesis_2003.pdf https://erlang.org/download/armstrong_thesis_2003.pdf It is just as relevant today as when it was written.

alkonaut 5y ago

> This file was also checked into a global CVS archive that all project members had access to. Today one might use GIT or SVN but any revision control system would do. Having locally created sequential ID's seems...strange. Or you simply have so few people creating ID's (and committing them so quickly) that it's not an issue. There are tons of ways of resolving this (such as author-prefixed ids "joe-23"). But simply calling it ticket++ in a global shared directory seems it could become a source of frustration and honestly a pretty inelegant solution to the problem. He mentions "doing one thing and doing it well" and being a "minimum viable program". One could argue that doing ONE thing reasonably when it comes to creating database records, is allowing me to create one without a conflicting ID. If the new_ticket command is actually immediately creating the entry in the central repository, retrying until it successfully allocates the next ID, then it works I suppose.

tpoacher 5y ago
Having made a similar project (see comment above: https://news.ycombinator.com/item?id=29965597 https://news.ycombinator.com/item?id=29965597 ) there's a (predictable? unexpected?) benefit to keeping a numerical index. It forces the ticket opener to commit as soon as possible, or risk having to re-index their tickets due to conflicts. This means that in any multi-member project, it encourages users to first check that a similar/duplicate ticket has not already made it into the repository in the meantime, and commit their tickets and make them visible to all other users with an accompanyign commit (and any notification-hooks that this entails) as soon as possible. Obviously you could also have a commit hook which reindexes tickets automatically, yes, but the focus here is all about simplicity and hackability first - and I think a behavioural solution is probably better than an automated one in this case anyway.
bachmeier 5y ago
> Or you simply have so few people creating ID's (and committing them so quickly) that it's not an issue. Rule #1 of minimum viable programs is to solve the problems you have rather than as something (number of users in this case) goes to infinity. If you're working with software developers and they can't trivially resolve a merge conflict of this nature, perhaps they are not the best at their craft.

tpoacher 5y ago

I created something similar when I had to work in an extremely resource-constrained project (we could only work by ssh'ing to a server with no graphical utilities, and no internet access other than ssh). It has worked like a charm, and I would find it difficult to go back to anything else for ticket management now. I use this for 'in-project tickets/milestones' and leave stuff like github issues for 'external' issues by users. Here it is on github for anyone who's interested: https://github.com/tpapastylianou/bashtickets https://github.com/tpapastylianou/bashtickets My tool is slightly less minimal than the one in the article, but essentially the same philosophy. Everything is a local file following a simple but fixed template, so that they can be grepped / manipulated if necessary. It plays very well with versioning, and supports milestones and 'advanced queries' as pre-made scripts. Obviously, since the tickets/milestones are simple text, it should be fairly straightforward to write your own queries if you know a bit of bash (or any other language you prefer, obviously). In fact, this little system has worked so well, that I have recently been trying to convert it to a nice, portable, "command-based" tool, i.e. the way git works; bashtickets init (or just bt init) initialises a ticket repository, bt new ticket creates a new ticket, bt list lists open/closed tickets, or active/completed milestones etc. There's nothing wrong with the original, of course, except for the fact that it's a bit ugly to have a bag of scripts in each ticket repository you want to manage. A command-based interface simply makes it look a bit more 'modern', and clean, putting any pre-made scripts and 'template' files out of sight for peace of mind. This is still very much under development, but please see the "commandbased" branch if interested [1]. I'd be very open to feedback :) [0] https://github.com/tpapastylianou/bashtickets [1] https://github.com/tpapastylianou/bashtickets/tree/commandbased

solididiot 5y ago

What kind of blog is that? I mean if you navigate to the index https://joearms.github.io/index.html#Index https://joearms.github.io/index.html#Index it says that this is actually a Quine.

CRConrad 5y ago
Yeah, from his WP link quines are, among other descriptions, "self-replicating programs". And in the same blog header he also says it's a TiddlyWiki. That's one of many kinds of TinyWikis, and a rather interesting one in that it's self-contained: The entire source code for its Wikifying is contained as JavaScript within the actual HTML page itself. I guess that's what he means; TiddlyWiki pages are kind of "self-replicating" and therefore kind of quines.

bertman 5y ago

>Twitter has a no fuss 140 character tweet box. Simple, easy to understand and minimalist. Sigh, good old times... Maybe add 2014 to the title.