11 ms·

A tech stack should be a well-balanced portfolio

93 points by chesterarthur 6y ago

jamil7 6y ago
I feel like this applies especially to the persistence layer, I pick postgres basically everytime, I don't want any surprises at that layer. The rest you can chuck out and rebuild without too much pain.
- kfk 6y ago
  I actually feel even better when I am persisting using static files (json, csv, parquet, etc.), but of course that's not always possible.
  - jamil7 6y ago
    I do this on mobile quite a lot too! flat json or csv.
  - twic 6y ago
    Three years ago, i would have agreed with you. Now, i have three years' worth of static files, and i am not so sure.
  - cpursley 6y ago
    The issue with this is there's no data consistency in the static files.
  - typon 6y ago
    I use sqlite in almost all cases. You wanna store a file? Just put it in as a string. The amount of benefit I have gained by defaulting to sqlite for most tasks is immense.
  - brlewis 6y ago
    I haven't done that in decades. Has something changed recently that made it easier to create an ACID data store with static files? Last I looked, ACID was tricky enough with static files that it was easier just to use PostgreSQL.
  - Scarbutt 6y ago
    A true unixer.
tango12 6y ago
Another rule/heuristic that seems to work well, along with Rule 4 from the article, is having a limited number of golden tickets per team. A golden ticket gets used up when you use a "new shiny thing" or "cool but not widepsread" thing. For us, the risky choice in our stack [1] was Haskell. It's been amazing and has paid off immensely, but the challenges are very real. Over time we've wanted to go whole in on things like ReasonML too, but we haven't pulled the trigger or made safer choices, because that one golden ticket has been used up. (I can't take credit for coming up with this, but I don't know who did! I'm sure it's already better articulated somewhere.) [1] https://github.com/hasura/graphql-engine https://github.com/hasura/graphql-engine
- Tomte 6y ago
  http://boringtechnology.club/ http://boringtechnology.club/ calls it "innovation tokens".
- WJW 6y ago
  I think the usual term is "innovation tokens", from the "choose boring technology" post at https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology. It's definitely very helpful in preventing projects from choosing all the shiny new tech at once while not preventing any all innovation at all. Some of the shiny tech is actually worthwhile, after all.
- _mattt 6y ago
  This is a great way of thinking about technical decision-making. I'm most familiar with this idea through the framing of "innovation tokens" from the essay "Choose Boring Technology" [1]. [1] http://boringtechnology.club http://boringtechnology.club
wiremine 6y ago
These are well-reasoned defaults. I think the same can be said of architectures, not just technologies. I.e., when you're starting out, a monolith is likely a solid approach: it's easier to reason able, easier to deploy and debug, etc. But as you scale, you need to rethink your approach.
twic 6y ago
> If you’re too boring it gets hard to recruit. You don’t want trend chasers joining, but good candidates have a healthy want and interest in new technology. I think this is worth examining in a lot more detail. I accept that candidates are going to be put off by obsolete or terrible technology. I wouldn't take a job working on a Java 1.7 codebase, for example. Or ATG (now Oracle Commerce) - i did three years on that, and will never touch it again. But if a candidate is motivated to take a job because they get to use shiny new technology, i would suggest that they are not, in fact, a good candidate. In my experience, magpieism is associated with weaker programmers; not the very worst, but second quartile, say - people who get very engaged with superficial details, but don't think about deeper things.
- davidgl 6y ago
  +1 for use of the term magpieism ;-)
  - certifiedloud 6y ago
    I didn't understand the reference. I looked it up and may have found it here: https://en.wikipedia.org/wiki/Magpie#Cultural_references https://en.wikipedia.org/wiki/Magpie#Cultural_references > In European culture, the magpie is reputed to collect shiny objects, often in fiction things like wedding rings or other valuable or significant objects (often causing consternation at the disappearance, and false accusation of humans in the plot of the story); the most well-known example probably being Rossini's opera "La Gazza Ladra" (The Thieving Magpie). Recent research [8] has shown that there is little truth in the legend, and that magpies - like many animals - are actually unsettled by shiny, blue, or otherwise unusual objects.
  - runawaybottle 6y ago
    Might be time for the Magpie stack, Rust based static file blog generator (compiled via WebAssembly) via AWS Lamdas written in Go, wait no, Deno. Or should there be a Rust based React framework? How would that work? If it exists then it’s gotta be more performant, so yeah, let’s use that. I don’t know if this is magpie enough now days. It’s hard to even make fun of this because the irony is even the joke becomes outdated lol.
maps7 6y ago
I feel like this blog post is written towards people who shouldn't be making these decisions. I think the people making decisions like this should be in a senior, experienced position.
- BigJono 6y ago
  There's stacks of people in senior positions that fuck this stuff up constantly. The start-up graveyard is probably full of companies where the CTO came in with an impressive resume then spent 2 years building some massive scale kubernetes clusterfuck for his 5 users while another company ate his lunch with a shitty PHP app.
  - staysaasy 6y ago
    Indeed, this unfortunately does happen. There are also very smart but relatively inexperienced people who need to pick good technologies due to circumstance. Younger technical founders or early engineering hires come to mind.
- Nextgrid 6y ago
  I have seen a lot of software "engineers" that forget the primary goal of software engineering (solving a business problem) and instead see engineering as the goal itself, building an over-complicated, over-engineered "playground" of microservices to serve a whopping 20 requests/second and requires a full-time DevOps team just to keep the stack running. At that point building the stack appears to be the main purpose and solving the business problem was a "nice to have" side effect.
lucb1e 6y ago
This convinced me the issue is not with people, it's with the system. If the author chose Markdown for their blog and yet can't seem to spare a single minute to read up on how it works, then I guess we can't expect people on HN, stackoverflow, etc. to learn it either. Input whitespace (including newlines) does not translate 1:1 to output whitespace in Markdown and this mistake happens a lot in comments here, on stackexchange sites, etc. https://dro.pm/a.png https://dro.pm/a.png More on topic, I find it a bit disheartening that people are discouraged from picking a niche library and are instead supposed to look at GitHub's star system. So if it's not on GitHub or if my users don't star it enough, you shouldn't consider it for use in production? Shouldn't the documentation, code quality, open issues / maintainer responsiveness to issues, etc. speak for itself?
- mattgreenrocks 6y ago
  > I find it a bit disheartening that people are discouraged from picking a niche library and are instead supposed to look at GitHub's star system. Yeah, it's pretty gross for two reasons: 1. Reinforces the broken belief that the best way to evaluate things is based on the perception of others, rather than the intrinsic qualities (like those you mentioned) 2. Adopts a purely consumeristic view of open source The striking thing is that now these sorts of views are said out loud with no sense of shame.
  - gridlockd 6y ago
    > Reinforces the broken belief that the best way to evaluate things is based on the perception of others, rather than the intrinsic qualities (like those you mentioned) It's not always the best way, it's a shortcut. While you're spending time figuring out which JSON library is the best by some metric that might ultimately be irrelevant to the task at hand, I'm going with the popular option that is almost certainly "good enough" for me - otherwise it wouldn't be popular. That gives me an advantage over you, 98% of the time. > Adopts a purely consumeristic view of open source I don't see how this relates to popularity. Most users of open source will always be consumers, whether something is popular or not. However, if something is popular, the likelihood of someone to contribute back also grows. Furthermore, if something is popular and there's an issue, somebody else will most likely run into it before me, write about it, get feedback on it, and so on. That's a valuable contribution, even though it isn't code.
AlchemistCamp 6y ago
A related discussion here was the cofounder of Scribd talking about how Rails was a fantastic decision but he wouldn't have picked it for a new startup at the end of 2015: https://jaredfriedman.wordpress.com/2015/09/15/why-i-wouldnt-use-rails-for-a-new-company/ https://jaredfriedman.wordpress.com/2015/09/15/why-i-wouldnt... https://news.ycombinator.com/item?id=10236210 https://news.ycombinator.com/item?id=10236210
sarreph 6y ago
This is the important line for me: > Every time you aren’t boring in a technology pick, you’re likely not optimizing for your company’s best interests. Really helps to underscore the difference between choosing something shiny and choosing something pragmatic and efficient. When we do the former (as I'm sure most of us gravitate towards), it's very easy to kid ourselves that we'll somehow make the product greater as a result, but in reality we're only serving our own interests (learning something new and fun) rather than the company's!
- WJW 6y ago
  Most people know this and have no problem with it. It's pretty well known that the company won't look out for your best interests so you'd better do it yourself.
jonnypotty 6y ago
Any real project would have real requirements. These real requirements are always going to trump a star rating system, 'what's popular' or a generic guide on the Internet. You should define your requirements and then pick the tech which is best at providing a solution to this requirement. What? I'm going to have a choice of two bits of tech and I'm gonna decide to use one over the other cos it's 'boring but not too boring'? Come on now. These are rules for people who don't know what they're doing aren't they? Understand your requirements. Understand the technology you propose to use.
jonnycat 6y ago
I would add: have a process or framework for evaluating and adopting new technologies. Sometimes new technologies end up as part of the stack through pure momentum (hey, we built this prototype...) rather than deliberate choice. Be mindful of what the technology is being used for and what the costs of changing down the road might be.
cabite 6y ago
Orthogonally to this, I also think that the code you write conditions the way you will update the code later, when adding features, fixing bugs or refactoring. Code has two sides: executed code and edited code. Both actions, executing and editing, obey some laws with respect to the resources these processes consume, such as time, (computer and human time) and space (RAM and file/LOC count). Theories which detail how processes consume resources apply to both computer and human processes dealing with code, be it as a running program, in the text editor or when it comes to team management. However you have to understand the results they give you depending on which operator executes the process you consider. We humans are very slow when compared to computers and as a consequence architectural decisions can greatly influence the time it takes to maintain a code base. As compared to computers we can handle less complexity classes. Code that takes polynomial time to edit is out of reach. Code that takes linear time is the most frequent case but it's barely OK. Editorially linear code is just like computationally polynomial programs: although for the sake of the mathematical argument we ignore them, constant factors do matter. This is more important I think than mitigating risk at the tech stack level (far above, from the management floor) since the benefits you gain in compressing code (architecturally speaking of course) outweighs tech stack balancing.

93 points by chesterarthur 6y ago

I feel like this applies especially to the persistence layer, I pick postgres basically everytime, I don't want any surprises at that layer. The rest you can chuck out and rebuild without too much pain.

kfk 6y ago
I actually feel even better when I am persisting using static files (json, csv, parquet, etc.), but of course that's not always possible.
- jamil7 6y ago
  I do this on mobile quite a lot too! flat json or csv.
- twic 6y ago
  Three years ago, i would have agreed with you. Now, i have three years' worth of static files, and i am not so sure.
- cpursley 6y ago
  The issue with this is there's no data consistency in the static files.
- typon 6y ago
  I use sqlite in almost all cases. You wanna store a file? Just put it in as a string. The amount of benefit I have gained by defaulting to sqlite for most tasks is immense.
- brlewis 6y ago
  I haven't done that in decades. Has something changed recently that made it easier to create an ACID data store with static files? Last I looked, ACID was tricky enough with static files that it was easier just to use PostgreSQL.
- Scarbutt 6y ago
  A true unixer.

tango12 6y ago

Another rule/heuristic that seems to work well, along with Rule 4 from the article, is having a limited number of golden tickets per team. A golden ticket gets used up when you use a "new shiny thing" or "cool but not widepsread" thing. For us, the risky choice in our stack [1] was Haskell. It's been amazing and has paid off immensely, but the challenges are very real. Over time we've wanted to go whole in on things like ReasonML too, but we haven't pulled the trigger or made safer choices, because that one golden ticket has been used up. (I can't take credit for coming up with this, but I don't know who did! I'm sure it's already better articulated somewhere.) [1] https://github.com/hasura/graphql-engine https://github.com/hasura/graphql-engine

Tomte 6y ago
http://boringtechnology.club/ http://boringtechnology.club/ calls it "innovation tokens".
WJW 6y ago
I think the usual term is "innovation tokens", from the "choose boring technology" post at https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology. It's definitely very helpful in preventing projects from choosing all the shiny new tech at once while not preventing any all innovation at all. Some of the shiny tech is actually worthwhile, after all.
_mattt 6y ago
This is a great way of thinking about technical decision-making. I'm most familiar with this idea through the framing of "innovation tokens" from the essay "Choose Boring Technology" [1]. [1] http://boringtechnology.club http://boringtechnology.club

wiremine 6y ago

These are well-reasoned defaults. I think the same can be said of architectures, not just technologies. I.e., when you're starting out, a monolith is likely a solid approach: it's easier to reason able, easier to deploy and debug, etc. But as you scale, you need to rethink your approach.

twic 6y ago

> If you’re too boring it gets hard to recruit. You don’t want trend chasers joining, but good candidates have a healthy want and interest in new technology. I think this is worth examining in a lot more detail. I accept that candidates are going to be put off by obsolete or terrible technology. I wouldn't take a job working on a Java 1.7 codebase, for example. Or ATG (now Oracle Commerce) - i did three years on that, and will never touch it again. But if a candidate is motivated to take a job because they get to use shiny new technology, i would suggest that they are not, in fact, a good candidate. In my experience, magpieism is associated with weaker programmers; not the very worst, but second quartile, say - people who get very engaged with superficial details, but don't think about deeper things.

davidgl 6y ago
+1 for use of the term magpieism ;-)
- certifiedloud 6y ago
  I didn't understand the reference. I looked it up and may have found it here: https://en.wikipedia.org/wiki/Magpie#Cultural_references https://en.wikipedia.org/wiki/Magpie#Cultural_references > In European culture, the magpie is reputed to collect shiny objects, often in fiction things like wedding rings or other valuable or significant objects (often causing consternation at the disappearance, and false accusation of humans in the plot of the story); the most well-known example probably being Rossini's opera "La Gazza Ladra" (The Thieving Magpie). Recent research [8] has shown that there is little truth in the legend, and that magpies - like many animals - are actually unsettled by shiny, blue, or otherwise unusual objects.
- runawaybottle 6y ago
  Might be time for the Magpie stack, Rust based static file blog generator (compiled via WebAssembly) via AWS Lamdas written in Go, wait no, Deno. Or should there be a Rust based React framework? How would that work? If it exists then it’s gotta be more performant, so yeah, let’s use that. I don’t know if this is magpie enough now days. It’s hard to even make fun of this because the irony is even the joke becomes outdated lol.

maps7 6y ago

I feel like this blog post is written towards people who shouldn't be making these decisions. I think the people making decisions like this should be in a senior, experienced position.

BigJono 6y ago
There's stacks of people in senior positions that fuck this stuff up constantly. The start-up graveyard is probably full of companies where the CTO came in with an impressive resume then spent 2 years building some massive scale kubernetes clusterfuck for his 5 users while another company ate his lunch with a shitty PHP app.
- staysaasy 6y ago
  Indeed, this unfortunately does happen. There are also very smart but relatively inexperienced people who need to pick good technologies due to circumstance. Younger technical founders or early engineering hires come to mind.
Nextgrid 6y ago
I have seen a lot of software "engineers" that forget the primary goal of software engineering (solving a business problem) and instead see engineering as the goal itself, building an over-complicated, over-engineered "playground" of microservices to serve a whopping 20 requests/second and requires a full-time DevOps team just to keep the stack running. At that point building the stack appears to be the main purpose and solving the business problem was a "nice to have" side effect.

lucb1e 6y ago

This convinced me the issue is not with people, it's with the system. If the author chose Markdown for their blog and yet can't seem to spare a single minute to read up on how it works, then I guess we can't expect people on HN, stackoverflow, etc. to learn it either. Input whitespace (including newlines) does not translate 1:1 to output whitespace in Markdown and this mistake happens a lot in comments here, on stackexchange sites, etc. https://dro.pm/a.png https://dro.pm/a.png More on topic, I find it a bit disheartening that people are discouraged from picking a niche library and are instead supposed to look at GitHub's star system. So if it's not on GitHub or if my users don't star it enough, you shouldn't consider it for use in production? Shouldn't the documentation, code quality, open issues / maintainer responsiveness to issues, etc. speak for itself?

mattgreenrocks 6y ago
> I find it a bit disheartening that people are discouraged from picking a niche library and are instead supposed to look at GitHub's star system. Yeah, it's pretty gross for two reasons: 1. Reinforces the broken belief that the best way to evaluate things is based on the perception of others, rather than the intrinsic qualities (like those you mentioned) 2. Adopts a purely consumeristic view of open source The striking thing is that now these sorts of views are said out loud with no sense of shame.
- gridlockd 6y ago
  > Reinforces the broken belief that the best way to evaluate things is based on the perception of others, rather than the intrinsic qualities (like those you mentioned) It's not always the best way, it's a shortcut. While you're spending time figuring out which JSON library is the best by some metric that might ultimately be irrelevant to the task at hand, I'm going with the popular option that is almost certainly "good enough" for me - otherwise it wouldn't be popular. That gives me an advantage over you, 98% of the time. > Adopts a purely consumeristic view of open source I don't see how this relates to popularity. Most users of open source will always be consumers, whether something is popular or not. However, if something is popular, the likelihood of someone to contribute back also grows. Furthermore, if something is popular and there's an issue, somebody else will most likely run into it before me, write about it, get feedback on it, and so on. That's a valuable contribution, even though it isn't code.

AlchemistCamp 6y ago

A related discussion here was the cofounder of Scribd talking about how Rails was a fantastic decision but he wouldn't have picked it for a new startup at the end of 2015: https://jaredfriedman.wordpress.com/2015/09/15/why-i-wouldnt-use-rails-for-a-new-company/ https://jaredfriedman.wordpress.com/2015/09/15/why-i-wouldnt... https://news.ycombinator.com/item?id=10236210 https://news.ycombinator.com/item?id=10236210

sarreph 6y ago

This is the important line for me: > Every time you aren’t boring in a technology pick, you’re likely not optimizing for your company’s best interests. Really helps to underscore the difference between choosing something shiny and choosing something pragmatic and efficient. When we do the former (as I'm sure most of us gravitate towards), it's very easy to kid ourselves that we'll somehow make the product greater as a result, but in reality we're only serving our own interests (learning something new and fun) rather than the company's!

WJW 6y ago
Most people know this and have no problem with it. It's pretty well known that the company won't look out for your best interests so you'd better do it yourself.

jonnypotty 6y ago

Any real project would have real requirements. These real requirements are always going to trump a star rating system, 'what's popular' or a generic guide on the Internet. You should define your requirements and then pick the tech which is best at providing a solution to this requirement. What? I'm going to have a choice of two bits of tech and I'm gonna decide to use one over the other cos it's 'boring but not too boring'? Come on now. These are rules for people who don't know what they're doing aren't they? Understand your requirements. Understand the technology you propose to use.

jonnycat 6y ago

I would add: have a process or framework for evaluating and adopting new technologies. Sometimes new technologies end up as part of the stack through pure momentum (hey, we built this prototype...) rather than deliberate choice. Be mindful of what the technology is being used for and what the costs of changing down the road might be.

cabite 6y ago

Orthogonally to this, I also think that the code you write conditions the way you will update the code later, when adding features, fixing bugs or refactoring. Code has two sides: executed code and edited code. Both actions, executing and editing, obey some laws with respect to the resources these processes consume, such as time, (computer and human time) and space (RAM and file/LOC count). Theories which detail how processes consume resources apply to both computer and human processes dealing with code, be it as a running program, in the text editor or when it comes to team management. However you have to understand the results they give you depending on which operator executes the process you consider. We humans are very slow when compared to computers and as a consequence architectural decisions can greatly influence the time it takes to maintain a code base. As compared to computers we can handle less complexity classes. Code that takes polynomial time to edit is out of reach. Code that takes linear time is the most frequent case but it's barely OK. Editorially linear code is just like computationally polynomial programs: although for the sake of the mathematical argument we ignore them, constant factors do matter. This is more important I think than mitigating risk at the tech stack level (far above, from the management floor) since the benefits you gain in compressing code (architecturally speaking of course) outweighs tech stack balancing.