Diseconomies of scale

An amazing article about how software development doesn’t follow economies of scale. If you go from 3 engineers to 4, the communication paths increase from 3 to 6.

When you release one feature, you test exactly one thing. Now you add another feature to release, you don’t just have to test 2 things, you need to test 3 things: the two features plus, their interaction among each other.

I think this article puts in words, what I’ve been preaching and practicing without being able to express. Super glad that we’re aiming for a small team at Dgraph. It just gives me more evidence that what I’ve been seeing with small teams achieving great things is not just a fluke; it makes logical sense.

The one thing that we should be changing is our release cycle. I think we should be releasing more frequently than we do right now. Smaller features more often, with micro-minor releases. So, if it breaks backward compatibility then v0.N where N = 1 + M (previous release). Otherwise, 0.N.X.


A lot of software follow Semantic Versioning, which is very close to what you are saying.

1 Like

Yup, that’s the one. The big change here is going to be the frequency of release, and how many features we release.

Waiting longer - and probably writing more code - before you ask for feedback or user validation causes more problems than asking for it sooner when the product is smaller.

Awesome article, maybe we should aim for fortnightly releases with lesser features.

1 Like

Which means, we’re currently pending one release, today :slight_smile:.