Corollary: if software requires constant revisions it didn't actually cover the initial problem scope, and degenerated into a high-latency service state-machine powered by coders. =3
Corollary: if software requires constant revisions it didn't actually cover the initial problem scope, and degenerated into a high-latency service state-machine powered by coders. =3
Makes sense for small tool like ls, and doesn't for things that are actually complex like the python language or sqlite.
It is a common misconception that permutation is progress, and popularity is justification for poor design-pattern choices.
Spiraling complexity often eventually implodes out-of-band ecosystems sooner or later. =3
The very idea of "let's just write it correct the first time" is itself very much a second system fallacy.
Standard project release cycles build to a design specification, clearly defining phases of what is acceptable and when.
https://en.wikipedia.org/wiki/Technology_readiness_level
One way to enforce implementation convergence is to define core unit tests before coding even begins. If people just ignored communication, the results are rather predictable.
https://en.wikipedia.org/wiki/Conway's_law
Building something that doesn't need patched every week is impossible for some. =3