2 ms·

This can be considered minimalist. For example: We use Heroku instead of a custom AWS setup We use Sentry instead of a hand rolled exception tracking system We

This can be considered minimalist. For example: We use Heroku instead of a custom AWS setup We use Sentry instead of a hand rolled exception tracking system We use Postgres instead of a custom We are minimalist in the sense that we minimize the code we have to maintain in house.

sanderjd 7y ago
That there are two opposite interpretations of "minimalist" in the article and thread with respect to build-new vs. use-existing decisions probably suggests that it isn't a very meaningful metric. It would be ideal if you could start with the tactic the article advocates and then easily switch from a stripped down custom approach to a more common denominator standard approach exactly when it begins to have better ROI. But in the real world, switching costs are high, ROI is impossible to measure perfectly, and there are other variables that matter a lot (like your future employees' familiarity with tools). My personal preference is in line with the article's suggestion - I strongly prefer building little purpose built things to reading documentation for and hacking around inconvenient parts of standard tools - but I tend to think it makes better business sense to go with the standard tools for things that aren't directly in your project's core competency.
- lazyasciiart 7y ago
  Minimalism isn’t a metric, because as you say, there is no object or method of measurement given. Might as well say that your metric is “betterness”. Better what?
- vendiddy 7y ago
  It's best handled case by case as with most decisions. Should one build their own database? Probably not. That introduces more complexity. What about an npm package to pad strings? It's simpler to write that logic than to deal with one more dependency. Giving two extreme examples to illustrate that "minimalism" may not be a useful criteria. So seems like we're in agreement :)

sanderjd 7y ago

That there are two opposite interpretations of "minimalist" in the article and thread with respect to build-new vs. use-existing decisions probably suggests that it isn't a very meaningful metric. It would be ideal if you could start with the tactic the article advocates and then easily switch from a stripped down custom approach to a more common denominator standard approach exactly when it begins to have better ROI. But in the real world, switching costs are high, ROI is impossible to measure perfectly, and there are other variables that matter a lot (like your future employees' familiarity with tools). My personal preference is in line with the article's suggestion - I strongly prefer building little purpose built things to reading documentation for and hacking around inconvenient parts of standard tools - but I tend to think it makes better business sense to go with the standard tools for things that aren't directly in your project's core competency.

lazyasciiart 7y ago
Minimalism isn’t a metric, because as you say, there is no object or method of measurement given. Might as well say that your metric is “betterness”. Better what?
vendiddy 7y ago
It's best handled case by case as with most decisions. Should one build their own database? Probably not. That introduces more complexity. What about an npm package to pad strings? It's simpler to write that logic than to deal with one more dependency. Giving two extreme examples to illustrate that "minimalism" may not be a useful criteria. So seems like we're in agreement :)