> If the change deployed is small, there is less code to look through in case of a problem. If you only deploy new software every three weeks, there is a lot more code that could be causing a problem.

That's relative. Pushing out an accumulated amount of small changes once a week will most likely have the same end the result. The difference is, if you commit more than one breaking change you are dynamically expanding the window of service degradation. One release with three breaking changes is better than three broken pushes.

> If a problem can’t be found or fixed quickly, it is also a lot easier to revert a small deploy than a large deploy.

It is also harder to revert two non-consecutive deploys out of three.

> If I deploy a new feature as soon as it is ready, everything about it is fresh in my mind. So if there is a problem, trouble shooting is easier than if I have worked on other features in between.

Personally, I favor stability vs. easier troubleshooting. This works for some products and not others.

> It is also frees up mental energy to be completely done with a feature (including deployed to production).

Anecdotal evidence, but my team would usually catch and correct bugs when they have to come back to green light a production push. Engineers that ship clean and fast are rare.

> All things being equal, the faster a feature reaches the customer, the better. Having a feature ready for production, but not deploying it, is wasteful.

Something like this would usually be pushed out manually to align with other non-engineering parties within your company. Pushing broken features to the customer faster is not a good thing. Unless you can assume 100% success rate; which is not possible.

> The sooner the customer starts using the new feature, the sooner you hear what works, what doesn’t work, and what improvements they would like.

This depends on the stage of the company, the product, and your customers.

> Furthermore, as valuable as testing is, it is never as good as running new code in production. The configuration and data in the production environment will reveal problems that you would never find in testing.

All of the environments I govern match production 1:1 (sans data sanitation) in every way possible. I feel pretty strongly about this, if you can't test your code without pushing it into production, you should not be automating anything.

> Continuous delivery works best when the developers creating the new features are the ones deploying them. There are no hand-offs – the same person writes the code, tests, deploys and debugs if necessary. This quote (from Werner Vogels, CTO of Amazon) sums it up perfectly: “You built it, you run it.”

Don't compare a start-up to Amazon. Amazon has dedicated teams to govern the process and you most likely not replicate that. Also, hiring people that 'just send it' without doing damage takes money, time and a lot of training. It's expensive.

What author fails to understand, is that the problem could have been addressed by collaboration as well.

I caught a 'scrum-master' CTO wanna-be that wrote an article about (omitting my name) how he is happy I was gone because I was hard to manage. This guy showed up and hanged his scrum-master certificate on the wall and promoted a (fresh out of college) junior developer to management because he was there for a year longer than me and proceeded to enable and reward the most idiotic technical decisions I have ever seen while the rest of us was battling scalability problems.

He never talked to me; he was in the room with his new director of engineering (1 year of non-management experience, seriously) trying to come up with a strategy on how to do things and then try to run with it without getting any feedback.

Obviously, I shot them down, and it got to the point where they would come up with this stuff (no communication) and could not provide any details (why will this work? why is it better?).

I simply quit and never looked back at that point, they probably did collaborate a lot more. And by collaboration, I mean circle jerk whatever ideas sound great and force them on junior developers that do not know any better.

Great question. I build something similar without a moisture sensor, the key to obtaining proper data is to know (and control) the exact amount of water you elect to distribute.

The self-learning (ghetto A.I) software that I wrote would try to predict the next (optimal) watering event. You can start to tell how much weight the water adds and how fast the plant consumes it after a couple of iterations. Plus the soil will usually outweigh a plant by a considerable margin.

You are comparing apples to oranges. Your $1500/month (from the past, different year, packages, car) lease payment is an obligation that requires a 24/36/48 month commitment.

I thought Coinbase had insurance that only covered the online portion but not offline vaults, where most of the 'money' is stored?

If an offline vault is compromised through their system then what? The promise of keeping things separate doesn't guarantee anything.

Comments URL: https://news.ycombinator.com/item?id=15295134

Points: 1

# Comments: 0

/s

You are unquestionably better than ignorant humans with liquid assets.

Your solution is too complicated and will not work. Why not just 'simply' build a bunch of cities on Mars and relocate?

Not really. Timezones are a thing and I'm pretty sure the majority of those exchanges halted trading.

The bullshit artists that already 'invested' in this scheme will now tell you that China did not matter and the people under them will parrot it.

Anybody that disagrees simply doesn't understand Bitcoin or just mad that they could not get on the choo-choo train at the right time.

The typical response was 'If X bans the cryptocurrency, we will just trade in another country. That's the whole point!'.

Can somebody explain what will happen if U.S starts to feel the pressure from Bitcoin and kills it at the point of exchange? Sure, you will still have your Bitcoins, but they will drop in value and become useless.

Furthermore, what will happen to the market if 1%'s attempt to convert a couple of billions to USD at the same time? Who will honor that transaction? The banks will not touch it.

This will end up just like the banking crisis sans a bailout. People can't get the 'money' out because the exchange rate is not going to be honored, and the value of their money will drop over night.

You are suggesting the exact opposite.

How can you tell? You are looking at a PR piece that links to a web site that mentions 'security experts' in every other sentence. It's not proven to be valuable or well executed.