5 ms·

Such a terrible advice. I've been several times involved in companies where this approach was followed, and where you could only run your own service with mocks

by midrus 6y ago

Such a terrible advice. I've been several times involved in companies where this approach was followed, and where you could only run your own service with mocks, and we had incredibly better results with the latter approach by a far, far, far amount. Just imagine an Amazon developer running amazon in its own laptop (or cluser, or server, or whatever... multiply it by the number of devs... it is insane).

johnobrien1010 6y ago
I one time met a guy who was trying to debug an issue he was having in production on a sprawling Django code base which he couldn't run in any other environment. It was impossible until he got the system running in the local environment. I also came on once to a set of projects where there wasn't a good separation of the environments; test and prod shared the same database, b/c it was "too hard" to replicate the prod data back to test. Consequently, no real DBA work could be done b/c it couldn't be tested, only small hot-patchy kind of work. Separation of concerns is a slightly different problem but the root cause of the issue is similar, you need to be able replicate the complexity of your system in production as much as possible in a lower environment, otherwise you won't be able to make as significant changes as you'd like to your system. I don't think this is terrible advice, while I recognize there are limits to what is possible to run locally/in lower environments, the central notion of 1) separation of concerns and 2)matching the complexity of the lower environment to production as much as possible is I think good advice.
nonameiguess 6y ago
So many +1s > Developers of large or legacy systems that cannot already be run in their entirety during development often believe that it is impractical to run the entire system during development. This is just a flat out ridiculous statement this author makes. My wife works on an automation system intended to respond to incoming events in the form of positive tips in surveillance system collections that in turn cues further tipping rules to retask those collection systems. One of the external dependencies is the entire spy satellite control system of the United States. How are you supposed to run this in your development environment? Some things you have to mock.
- juangacovas 6y ago
  I think the spirit of the article is: you should be able to "download real data from yesterday until now", and be able to run the system locally (or in a stage server wherever). Sure, with some mocks or not, but that's super convenient for testing, debugging, etc. without having to risk nasty "write tests" in production
  - stqism 6y ago
    Downing real data at a lot of companies sounds like a PII nightmare.
kerblang 6y ago
Stating the obvious but the problems start when you pretend you're Amazon on 1/100000th of Amazon's budget, and you can't keep up with the costs and complexities of trying to be like them. The author's advice is probably derived from smaller-scale experience - not necessarily even startup work, just low-budget, small, inexperienced teams, etc.
cpufry 6y ago
ha you'd be surprised how many services run their own development instances per developer

by midrus 6y ago

johnobrien1010 6y ago

I one time met a guy who was trying to debug an issue he was having in production on a sprawling Django code base which he couldn't run in any other environment. It was impossible until he got the system running in the local environment. I also came on once to a set of projects where there wasn't a good separation of the environments; test and prod shared the same database, b/c it was "too hard" to replicate the prod data back to test. Consequently, no real DBA work could be done b/c it couldn't be tested, only small hot-patchy kind of work. Separation of concerns is a slightly different problem but the root cause of the issue is similar, you need to be able replicate the complexity of your system in production as much as possible in a lower environment, otherwise you won't be able to make as significant changes as you'd like to your system. I don't think this is terrible advice, while I recognize there are limits to what is possible to run locally/in lower environments, the central notion of 1) separation of concerns and 2)matching the complexity of the lower environment to production as much as possible is I think good advice.

nonameiguess 6y ago

So many +1s > Developers of large or legacy systems that cannot already be run in their entirety during development often believe that it is impractical to run the entire system during development. This is just a flat out ridiculous statement this author makes. My wife works on an automation system intended to respond to incoming events in the form of positive tips in surveillance system collections that in turn cues further tipping rules to retask those collection systems. One of the external dependencies is the entire spy satellite control system of the United States. How are you supposed to run this in your development environment? Some things you have to mock.

juangacovas 6y ago
I think the spirit of the article is: you should be able to "download real data from yesterday until now", and be able to run the system locally (or in a stage server wherever). Sure, with some mocks or not, but that's super convenient for testing, debugging, etc. without having to risk nasty "write tests" in production
- stqism 6y ago
  Downing real data at a lot of companies sounds like a PII nightmare.

kerblang 6y ago

Stating the obvious but the problems start when you pretend you're Amazon on 1/100000th of Amazon's budget, and you can't keep up with the costs and complexities of trying to be like them. The author's advice is probably derived from smaller-scale experience - not necessarily even startup work, just low-budget, small, inexperienced teams, etc.

cpufry 6y ago

ha you'd be surprised how many services run their own development instances per developer