Skip to content

Instantly share code, notes, and snippets.

@dominykas
Last active August 29, 2015 14:15
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dominykas/9c8d94bc9927b5dbce3f to your computer and use it in GitHub Desktop.
Save dominykas/9c8d94bc9927b5dbce3f to your computer and use it in GitHub Desktop.

The problem I've been facing lately is decisions. There is too little time to make good decisions. And working a startup, there's too few team mates that can help you make these decisions.

It is impossible to understand the tradeoffs completely. It is also hard to understand them objectively. Hunches and wants get lots of help from confirmation bias. I'm not even sure that choosing node, choosing 12factors, choosing microservices-ish things are objectively good. I sure as hell have wondered if node is the right decision: https://speakerdeck.com/dymonaz/node-dot-js-the-smallprint - as with everything else, I guess.

I want a set of decisions, a starter kit, if you will, that will not hinder your progress in the future. This probably boils down to being able to reverse your decisions. Some might be easy - CentOS or Debian. VM or container. But Mongo vs MySQL? Is there an easy way out of it? The typical advice is to go with what you already know. But if you do - you will not get out of your comfort zone and you will not grow. So there must be some balance there as well.

The decisions that have to be made in starting a completely brand new project usually boil down to the same tradeoffs - performance, development speed, maintenance costs. There might not be a set of standard solutions for all stages of a project - a startup to a corporation - but there must certainly be a set of decisions that will allow you to replace them down the road. This means that the Microsoft stack is out :) The tradeoff here is that someone has to go through the learning curve and un-steepen it.

The same set of decisions may also be redefined as "goals" for legacy apps. The only difference being that you take a different path to achieve it. Even so - the methods of converging and refactoring your way out of crap are probably similar. There probably are some "no-brainer" technologies that one must use, e.g. Vagrant. There's probably a set of "good practice" things as well, e.g. 12factors. But certain things, like bare metal vs cloud, will always have an answer of "it depends".

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