Live data from Hacker News

All of us test in production all the time (2019)

increment.com

11–20 of 164 posts

Re: All of us test in production all the time (2019)

#12
Well no, but actually yes.

Kind of like how you don't get requirements from talking to customers or "the business". You get requirements from demoing. If your first demo is your prod deploy, then guess what, you've just deployed a proof of concept. It's a de facto thing that just happens even if you don't plan on it. In fact it happens BECAUSE you don't plan on it.

More to this point: there are many different kinds of tests and what we are most commonly referring to is "regression tests". There are lots of bugs that are not due to regressions.

Re: All of us test in production all the time (2019)

#15
A lot of this boils down to the constant churn in frameworks, instrumentation, programming languages. Developers don't have time to master one way of doing things, it's just a constant lava layer of crap.

I took the time to learn how to build and maintain Ruby on Rails systems, hoping it would be the ticket to a fun, manageable career. Any project I worked on was an island of sustainable, fast development where the team finished the sprint's work in a few days. I knew where the bottlenecks were should the project need to scale, and scaling issues never took down the site completely.

Only to throw all that expertise away when it was just decided to replatform one day. Because I guess stable just wasn't good enough. After it happened twice, well, might as well go into devops. Y'all are gonna need it.

Re: All of us test in production all the time (2019)

#16
It seems likely that some of the comments here are reacting to the headline as opposed to reading the article - which is one of my favourite pieces of writing on the subject of observability and responsible maintenance of large scale systems.

Lots of great quotable bits in here. Here's just one for people who didn't make it to the bottom:

"There’s a lot of daylight between just throwing your code over the wall and waiting to get paged and having alert eyes on your code as it’s shipped, watching your instrumentation, and actively flexing the new features."

Re: All of us test in production all the time (2019)

#17
post #9

This article is inane to me. Someone decided to write a lengthy blog post on the deliberate and obvious misinterpretation of a meme. DevOps and Observability are well described disciplines. I don't know anyone who has uttered the meme "I don't always test, but when I do, I test in production" who meant that monitoring, observing and reviewing prod behavior is bad. They invariably meant that they were rushed to releas…

The opinion of the article is that the catchphrase has become an excuse to build poor observability and in-prod testing tools, and we should be better about that.

The problem is that this article is misusing the catchphrase and now people are discussing the misuse of the meme instead of the article's content.

Re: All of us test in production all the time (2019)

#18
post #12

Well no, but actually yes. Kind of like how you don't get requirements from talking to customers or "the business". You get requirements from demoing. If your first demo is your prod deploy, then guess what, you've just deployed a proof of concept. It's a de facto thing that just happens even if you don't plan on it. In fact it happens BECAUSE you don't plan on it. More to this point: there are many different kinds o…

"You get requirements from demoing."

I really like that - what an insightful observation, neatly condensed into a few words.

Re: All of us test in production all the time (2019)

#19
post #14

Test in prod is terrible. Write unit and integration tests, test on staging, and then monitor Prod.

Sorry to make the assumption that you didn't read the article, but it really sounds like you didn't and are just making a comment about the headline. I would recommend reading the article.

Re: All of us test in production all the time (2019)

#20

A lot of this boils down to the constant churn in frameworks, instrumentation, programming languages. Developers don't have time to master one way of doing things, it's just a constant lava layer of crap. I took the time to learn how to build and maintain Ruby on Rails systems, hoping it would be the ticket to a fun, manageable career. Any project I worked on was an island of sustainable, fast development where the t…

> After it happened twice, well, might as well go into devops.

My observation of the devops world is that the rotation of technologies and frameworks there is faster than in backend development.

Post reply on HN