drol3's comments

Cool :)

Sometimes seeing the same concept from different perspectives makes it easier to understand. For a scala treatment of the same topic see

https://underscore.io/blog/posts/2017/06/02/uniting-church-a...

Also in Scala; an interesting solution to the expression problem:

https://i.cs.hku.hk/~bruno/papers/Modularity2016.pdf

Its a paper, but its very light on dense academic prose and very heavy on copy pastable code :)

I like the idea. Not sure it works on its own, but something like "Investment in tools should be proportionate to your knowledge about the domain" seems reasonable.

Beginner? Pick an cheap tool. Expert? pick the best tool :)

I am working for a company that has moved from 3 to 15 backend developers and 25 to 50 services over the last year.

The amount of services is really quite meaninglessness compared to the amount of developers. As with anything the efficiency good down as the amount of people goes up. There is no way that 2000 people can agree on anything. So most likely there is lots and lots of overlap.

You could probably refactor some of this duplication out, but by the time you would be done new duplication would have emerged. Keeping many people in sync is just difficult :)

Anyway the point is that 2200 services is meaningless without telling how many employees are working on said services :)

Great news!

Was my only blocker :)

I am continually impressed with the changes Microsoft has made since Satya Nadella took over :)

Huge fan of this kind of thinking.

I try to recommend this technique with software all the time. Basically instead of the workflow bring this

1) follow some tutorial online 2) integrate into real work

I do

1) follow some tutorial online 2) spend an hour to see how I can break it 3) integrate into real work

That step two does all sorts of wonderful things like helping you understand failure modes, better understand quality, make it easier to debug. You get the same knowledge over time by doing "real work", but it is much much more efficient this way :)

Thank you so much for all that you have done. Redis is a fantastic piece of work. It is everything software is supposed to be: it's simple and it just works :)

Good luck exploring your other options

I think we can all agree that software should be designed to last :)

My experience tells me that when this fails to happen its usually not explicitly due to too many dependencies. Rather it is because the developers have a poor/partial understanding of the problem domain.

External libraries help this problem a bit because it allows developers to offload tasks onto other more experienced developers. They can (and occasionally will) misuse those solutions, but that is not the dependencies faults. On the contrary skilled developers will produce quality solutions with or without dependencies.

The signal seen (poor software has many dependencies) does not mean that software with dependencies are poor. It means instead that developers who have a poor domain understanding but good business skills are disproportionately successful compared to their peers that have good domain understanding but poor business skills.

Make of that what you will :)

In my mind it's surprisingly simple: you VERY honestly ask yourself the question of you know exactly what you are building. If you do then don't be afraid to plan ahead. If you don't, then ship the smallest thing that works :)

If you are doing a rewrite of an existing system or have many years of experience with a similar product then thinking ahead can save time. Otherwise you are probably better of not trying to be too clever.

The difficult part for most people is actually being honest in the process :)

Also Kent Becks timeless advice is good to keep in mind

1) make it work

2) make it right

3) make it fast

In that order. You might not need all three :)