5 ms·
> If you discovered the tool on Hacker News and it's less than 18 months old — 'Danger, Will Robinson!' You shouldn't fear new things. Keep it simple, keep it
by dbg31415 10y ago
> If you discovered the tool on Hacker News and it's less than 18 months old — 'Danger, Will Robinson!'
You shouldn't fear new things. Keep it simple, keep it smart, and embrace what works for your team. Don't shun things because they're old, don't shun things because they're new. Shun complexity.
How about a real-world examples? Slack, Google Docs, and ZenHub. All of these added value right out the gate.
I first read about Slack in February 2014 on Hacker News.
* We Don’t Sell Saddles Here – Medium || https://medium.com/@stewart/we-dont-sell-saddles-here-4c59524d650d#.b9koamhnq https://medium.com/@stewart/we-dont-sell-saddles-here-4c5952...
Started playing with it, then started using it. It's helped my team move much faster. Slack added value. No reason not to use it. Same for ZenHub, same for Zapier, same for Docker, same for a bunch of other tools where I can say, first-hand, that being an early-adopter paid off vs. using something "tried and true."
Oh, and on that note, I freakin love Marker! (=
* Marker - Annotated Screenshots Sent to any Bug Tracking Tool || https://getmarker.io/ https://getmarker.io/
- rdtsc 10y ago> You shouldn't fear new things. I found one easy way is to just ask the person using the technology why they are using it. As long as they understand the trade-off and understand how it works, that's fine. If they say because they've seen stories on HN or at latest meetup someone mentioned, or it's "async so therefore faster", then be worried. I used to be that person out of college who didn't know and just went by whatever seemed more popular or whichever project had the coolest front page with most futuristic looking hexagons and such on it.
- dwaltrip 10y ago> You shouldn't fear new things Keep it simple, keep it smart, and embrace what works for your team. Don't shun things because they're old, don't shun things because they're new. Shun complexity. Often times, new things haven't fully mastered the complexity of the target domain. Also, they might work now, but will it work next year, if the project or service is abandoned? Using new things is fine, but we should be aware of these potential drawbacks. The examples you give are great, but how many other tools were posted in 2014 and since have gone kaput? Gotta watch out for survivorship bias.
- bbrazil 10y agoI like the idea of innovation tokens: http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology Basically you get 3 things per project where you can use something that's not tried and true.
- snom380 10y agoFrom the article, it doesn't seem like he's talking about tools like Slack. If that goes down, maybe it affects your productivity, but probably not your production systems. What he warns against is betting too early on core technologies like service discovery, deployment systems (Docker etc), database systems (MongoDB) And from reading HN posts, it sure seems like there's no shortage of people being burnt by that.
- avifreedman 10y agoYep, sorry if it didn't come through clearly enough. I was talking about (without trying to pick on any particular projects/vendors) infrastructure glue components - db, deployment/orchestration, storage, discovery, ... Maybe 'tool' was the wrong word, and 'component' would have been more clear.
- jacques_chester 10y agoHow do you feel about PaaSes like Cloud Foundry or OpenShift? They are, to greater or lesser degrees, able to present a uniform platform to developers across various backends (CF runs on OpenStack, AWS, Azure, GCP, vSphere or raw hardware via RackHD). So long as you deploy your own services using the same tooling (BOSH), it's possible to hoist and relocate a lot more easily than relying directly on the IaaS's services. Disclosure: I work for Pivotal, the majority contributor of engineering to Cloud Foundry and BOSH.
- avifreedman 10y agoI think they can be pretty efficient and if a handle is kept on what's deployed on top, can be not that much overhead over the cost of the infra (whether it's owned or cloud). But that keeping a handle on things is key - starting w/o a DBA is nice but if no one is tracking tables or how they're used things can get pretty expensive :) Specifically re CF - have seen a few companies use CF to do multi-infrastructure, but a lot of the companies we work with have 5-10 roles and just run them via config mgmt to deploy or now docker +/- k8s, and don't use PaaS at all.