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 :)
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 :)
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.
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
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 :)