A tech stack should be a well-balanced portfolio

Re:A tech stack should be a well-balanced portfolio by tango12 on Thursday June 11, 2020 @08:49AM (#23488229)

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

[ Parent | on HN ]

Re:A tech stack should be a well-balanced portfolio by WJW on Thursday June 11, 2020 @09:07AM (#23488388)

I think the usual term is "innovation tokens", from the "choose boring technology" post at 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.

[ Parent | on HN ]

Re:A tech stack should be a well-balanced portfolio by _mattt on Thursday June 11, 2020 @09:07AM (#23488394)

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

[ Parent | on HN ]

Re:A tech stack should be a well-balanced portfolio by Tomte on Thursday June 11, 2020 @09:04AM (#23488366)

http://boringtechnology.club/ calls it "innovation tokens".

[ Parent | on HN ]