4 ms·

> 1. There are few indicators of effective software engineering so strong as deployment frequency and lead time for changes. Being able to go from issue to fix

> 1. There are few indicators of effective software engineering so strong as deployment frequency and lead time for changes. Being able to go from issue to fix in production in minutes rather than days opens up completely new paths for feedback and allows you to operate your service much more efficiently This is only true under certain assumptions. E.g. if your business is not a public facing website, you often don't have the immediate feedback in case of errors, to make the above observation applicable. I have a customer with an application that gather date for a whole year, and then does alot of stuff with it. Then, there are no short feedback cycles in production, no matter how often a day you deploy. Then, it is important to assure quality before a change reaches production. Otherwise it might replace your data with background noise and you only discover it at the end of the next year. This is a symptom of the general tendency in developer circles to assume that personal findings apply to everyone at every time in every situation. Which is obviously ridicoulous. But somehow completely acceptable if you generalize from something one Google employer has posted about.

kqr 7y ago
There's a point to what you're writing that I hadn't considered, but I'd still hold that building "software used every day, or at least every week" constitutes far more of our collective engineering time than "software used once a year or more rarely." Even if the latter category is more numerous, I think we spend much less time working on it. And software that's used semi-frequently can benefit from a shorter feedback cycle, even if it doesn't have one right now. Sometimes there's an insurmountable technical barrier to that (e.g. code on a solar orbiter) but it's even in those cases worth investigating.

kqr 7y ago

There's a point to what you're writing that I hadn't considered, but I'd still hold that building "software used every day, or at least every week" constitutes far more of our collective engineering time than "software used once a year or more rarely." Even if the latter category is more numerous, I think we spend much less time working on it. And software that's used semi-frequently can benefit from a shorter feedback cycle, even if it doesn't have one right now. Sometimes there's an insurmountable technical barrier to that (e.g. code on a solar orbiter) but it's even in those cases worth investigating.