4 ms·

> So I was shocked to find that running an empty Python unit test at Dropbox took tens of seconds. Worse, when you fixed a bug and landed it, depending on how t

> So I was shocked to find that running an empty Python unit test at Dropbox took tens of seconds. Worse, when you fixed a bug and landed it, depending on how the daily push went, it might make it to production within a day? Two? Maybe more? Is it just me, or does this seem like an extremely aggressive release mentality and set of expectations? Most places I'm aware of might do 2 or less a week, sometimes once a month. This engineer is complaining it took a day to release some sort of bugfix? Are most engineers and companies in 2019 operating like this, where is their time for a dev and QA cycle first? A unit test is only as good as what you wrote it to catch, real life bugs slip through unit tests all the time.

idunno246 7y ago
Every Bay Area company I’ve worked for(except 1) does not have QA. It’s expected by the time the dev merges it it’s been appropriately tested and can go straight to prod, so no need to wait. Fewer, smaller releases is generally better when something does go wrong as well, it’s more obvious which change is the problem. The one that did have qa, the devs were incredibly lazy about testing, relying entirely on someone else to make sure it worked. I’d say the overall product was better with qa but the point at which a developer called it done was way worse.
lawn 7y ago
Its quite interesting how different software companies treat their releases. At my job we have major releases twice a year, and patches a couple of times between those.
sethammons 7y ago
We can have a bug discovered, patched, tested, validated, and deployed same day. If it is small. Usually a bug may or may not make it in this sprint depending on criticality. Then we will fix it in some number of days, qa the next day and deploy that same day. Multiple deploys per week or even day happen on my team.

idunno246 7y ago

Every Bay Area company I’ve worked for(except 1) does not have QA. It’s expected by the time the dev merges it it’s been appropriately tested and can go straight to prod, so no need to wait. Fewer, smaller releases is generally better when something does go wrong as well, it’s more obvious which change is the problem. The one that did have qa, the devs were incredibly lazy about testing, relying entirely on someone else to make sure it worked. I’d say the overall product was better with qa but the point at which a developer called it done was way worse.

lawn 7y ago

Its quite interesting how different software companies treat their releases. At my job we have major releases twice a year, and patches a couple of times between those.

sethammons 7y ago

We can have a bug discovered, patched, tested, validated, and deployed same day. If it is small. Usually a bug may or may not make it in this sprint depending on criticality. Then we will fix it in some number of days, qa the next day and deploy that same day. Multiple deploys per week or even day happen on my team.