Skip to content

Instantly share code, notes, and snippets.

Created April 1, 2014 23:08
Show Gist options
  • Select an option

  • Save anonymous/9924926 to your computer and use it in GitHub Desktop.

Select an option

Save anonymous/9924926 to your computer and use it in GitHub Desktop.
The Scalable Manifesto

Principles behind the Scalable Manifesto

We follow these principles:

Our highest priority is ideas with value, and long-term value is greater than short-term value.

Software is a collection of ideas, formulated in a consistent manner that e.g. computers can parse and execute.

On a universal scale most products ever created have zero value--they will not even be possible to use fifty years from now, and the same goes for a lot of the software written for these products.

The best ideas, architectures, and designs with long-term value has emerged from geniuses or experts that worked alone.

Sometimes they can benefit from other geniuses to discuss with, preferably without having to interact with them on an interpersonal level.

This is why the World Wide Web was created.

Aim for your software to still exist and be useful to someone even after your product and its original users are gone, since that gives a higher universal return on investment.

Don’t focus too much on the business logic or customer’s needs, since your business and customers are not likely to be around more than a few years at best.

Open-source as much of your software as possible and put most of your energy on these parts, since these are more likely to have long-term value for others, possibly even after your and your company’s deaths.

The software should be able to be developed also in the absence of human sponsors, developers, and users.

The only scalable method of conveying information to and within a development team is written communication that is available to all developers, including the machines that will soon replace you.

Don’t release software that you are not satisfied with, because there will probably never be time to make it better once it’s shipped, unless it’s obviously broken.

If you don’t have time to make it better now, when it’s relatively easy to do since you already have the right mental context, what makes you think you will have more time or inspiration to do it at some point in the future? You will probably just move on to other more urgent problems, and your code will never be # FIXME: this should be fixed at some point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment