Re^8: "When code reuse turns ugly"

The point about Continuous Integration is that it requires 100% adherence to strict testing.

Which is fine and dandy if your dependency supplier's are as rigorous as you are. You have that confidence?

The point is that dependency changes don't have to make it through your testing to affect your development.

And, with programmers writing the tests that verify their own code, if a dependency programmer gets the wrong end of the stick; or has a bad day, his code probably will satisfy his tests and make it through to his production branch without error. And it may not break the intermediaries test -- they haven't written any tests for the specific change and nothing breaks in their code, so it gets waved through by the automated processes.

Its only when it hits you that things break. What do you do? Back out the automated change and hope it'll go away? Or try to write a fix?

If you back out the change; what happened to Continuous X? And how long do you wait before trying again?

And if you look for a workaround; how much effort should you expend given the possibility that you'll have to revert it all next Wednesday?

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^8: "When code reuse turns ugly"