Nathan Epstein May 8
Software projects famously suffer from unforeseen complexities that slow development and undermine teams' ability to execute on high level objectives. In light of this, the desirability of developing "antifragile" software projects that grow stronger through this complexity - as opposed to collapsing under it - should be obvious. What follows are a few principles aimed at achieving this.
Prefer dependency on software with a long history of use
Project requirements are generally complex, incompletely specified, and non-static over time. For the most part, this means that a demonstrated history of usefulness should be weighed more heavily than rationalizations about a technology's value.
Software that survives through a long period of wide use has a demonstrated ability to handle practical complexity beyond that of newer software. This translates directly to a longer expected shelf-life. From this, we get "Lindy effects" where the longer a technology has been used, the longer it is likely to continue to be in use.
By way of contrast, SQL has been around for decades and shows no signs of going away any time soon. Through extensive use, features which could easily be rationalized as weaknesses (a generally insecure text-based API for example) have revealed themselves to be strengths (by allowing non-technical business users to explore data without an engineer). Time, and not narrative, is the judge.
This seems like an intuitive result. Given even odds, how many people would bet that SQL will be outlasted by a newer and "better" alternative like, say, MongoDB?
Prefer dependency on software that is used by its maintainers
But if you have to go with something new, its preferable to use software which is used by its authors. This creates a sensitivity to unpredictable challenges and will tend to lead the project to get stronger with time. If the author is using a project, emergent issues will prompt corresponding feature development. Conversely, an author who doesn't actively use their project will develop to match a preconceived mental model of reality instead of the real thing.
Consider the example of AngularJS vs. React. AngularJS grew quickly based largely on the excitement surrounding the fact that it was developed by Google. The rationalization was something like "Google has a lot of money and smart people, so their framework will obviously be great". But Google famously didn't use AngularJS for their own projects; their design turned out to be poorly suited to real projects and was abandoned for a whole sale re-write in the form of Angular 2.
By way of contrast, React is used by Facebook (which maintains the framework). The project has been growing rapidly, is healthily maintained, and appears to be the best active possibility for stability within the JS ecosystem.
According to the Stack Overflow Developer Survey (2017 and 2018), the percentage of respondants using Angular dropped from 44.3% to 36.9% while those using React jumped from 19.5% to 27.8%. This indicates a massive migration from Angular to React which shows no signs of slowing.
Prefer project owners over issue owners
In organizing software development work, prefer assigning people to high-level projects over low-level tasks. The reason for this is similar to the above argument about preferring software used by its authors. In completing small incremental tasks, it's easy to introduce technical debt for temporary expendience; project ownership creates incentives to avoid this kind of practice.
A developer tasked with specific, contained features has incentives to trade the long term health of the project for ease of development / efficiency in the short term. A project owner will recognize their own exposure to long term issues and be inclined to make technical decisions which support the long term health of the project; new challenges will lead to project growth opportunities - instead of buried time bombs.