Quality software, n. 2007: "we release when it's ready" 2017: "we're always ready to release"
-
-
Admittedly I have no data to back up my claim... perhaps just something to ponder on.
-
I've found, counterintuitively, practicing full continuous deployment increases velocity and quality.
-
But you have to do it correctly. Break things up into very small, shippable units. Automated tests are included in the def of "shippable"
-
Right. Continuous deployment forces automation which improves quality.
-
Think back to punched cards - slow to deploy == more thought upfront in general. Not saying we go back to cards though!
-
Ok I see what you're saying. I took the original post as commentary on how CI/CD has changed the industry.
-
The up front thought fundamentally restricted the kinds of things you could build because frequent contact w/ reality is critical for design
-
Think about the quality of something like Office 2003 vs Dropbox Paper or Google Docs.
- 1 more reply
New conversation -
-
-
In the last three weeks, 52 apps on my phone have been updated, which is entirely typical. Many updates labeled exclusively "bug fixes".
-
I think Office 2003 had a lot of bugfixes. Just took a few years to ship.
-
I'm sure it did. Yet you're changing the subject, methinks. CI/CD is cool, but mostly to technologists. It feels like a fetish to me.
-
There IS value in being able to deploy rapidly, if there's a good business reason for it. Question is, is there?
-
You're assuming bugs are introduced per release rather than per unit of effort. Conversely, Bugs are fixed through contact with reality.
-
Bugs are *discovered* through contact with reality. One important venue for reality is testing—which we can do independent of deploying.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.