April 12, 2017 at 10:22 am
roger.plowman - Tuesday, April 11, 2017 7:39 AMIt's all fun and games until a hacker breaks in and leaks your data.Look, trumpeting automated testing is missing one critical point. Yes, automated tests *help*, but they Do. Not. Solve. The. Basic. Issue.
Automated testing cures the known knowns, might do something with known unknowns but by definition can do squat all against unknown unknowns.
Case in point, 0-day vulnerabilities. With all the compiler checks and automated tests in the world these "bug reducing" companies are hacked with embarrassing regularity. Bugs abound *still*.
You depend on automated testing and you're going to catch the bugs you know could happen. The people who write the tests are usually the same ones who write the code.
What have we learned about programmers checking their own code?
Exactly.
DevOps is not a silver bullet. DevOps is a codified way to overdrive your lights.
Slow down. HIRE A DAMN QA DEPARTMENT. One that knows how to find the weird stuff.
Don't get me wrong, I love automated testing. As a lone wolf it's one of the few ways I can get *any* testing done, Lord knows the users won't do it. But at the same time I'm keenly aware of just how (in)effective they can be, especially in complex database apps.
DevOps does not exclude provisioning a QA team. It also is not automated tests.
Having said that I would rather be in an environment that tested the known knowns through automation before every release than one that didn't.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 12, 2017 at 10:29 am
Rod at work - Tuesday, April 11, 2017 8:26 AM...Unit testing is very important. I helped bring that to my new job. However, I wonder what purpose unit testing has in an organization such as the one I'm in where there's no interest at all in DevOps and especially no interest in rapid deployment. All deployments must be approved by committee and if that takes weeks, so be it. I'll still do unit testing, but it seems less useful than I thought it would, when I first came here.
Unit testing often seems to be a waste of time until it saves someone. Sometimes developers don't even let on that unit tests run locally have stopped them breaking the build/product so the rest of the team are oblivious to the value the unit tests have made to their day. It is worthwhile and it does enable other techniques and processes. I would bet that over time you will see more and more incidents that demonstrate its worth. And probably guess that many more were hidden from you and your colleagues.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 13, 2017 at 9:28 am
Gary Varga - Wednesday, April 12, 2017 10:29 AMRod at work - Tuesday, April 11, 2017 8:26 AM...Unit testing is very important. I helped bring that to my new job. However, I wonder what purpose unit testing has in an organization such as the one I'm in where there's no interest at all in DevOps and especially no interest in rapid deployment. All deployments must be approved by committee and if that takes weeks, so be it. I'll still do unit testing, but it seems less useful than I thought it would, when I first came here.Unit testing often seems to be a waste of time until it saves someone. Sometimes developers don't even let on that unit tests run locally have stopped them breaking the build/product so the rest of the team are oblivious to the value the unit tests have made to their day. It is worthwhile and it does enable other techniques and processes. I would bet that over time you will see more and more incidents that demonstrate its worth. And probably guess that many more were hidden from you and your colleagues.
You're probably right, Gary. Perhaps its best to think of unit testing as something separate from DevOps. Unit testing fits in well with DevOps. However, what you've said suggests that unit testing can exist separate from DevOps. Perhaps even in waterfall. Within the waterfall environment I think unit testing may be considered a curiosity, but perhaps one day it will save someone's bacon.
Kindest Regards, Rod Connect with me on LinkedIn.
April 13, 2017 at 11:08 pm
Does Speed Compromise Quality?
Interesting question. I am reminded of the ol' production triangle question of having it good, fast, or cheap and only being able to pick 2. I always pick good and the other two usually follow because then you're not having to be distracted by rework (which costs and slows down the main vein of work). As the team practices doing it right time after time, they get better and faster and that also means a job gets done for less. I rather think of it as a "success spiral".
A lot of companies miss that by going for fast or cheap as the primary goal and end up in a "death spiral" of rework and failures.
So, to reverse the question, "Does Quality Enhance Speed"? I'd have to say yes. "Does Speed Compromise Quality"? I'd have to say "It Depends" on how the speed is achieved.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 14, 2017 at 6:41 am
Jeff Moden - Thursday, April 13, 2017 11:08 PMDoes Speed Compromise Quality?
Interesting question. I am reminded of the ol' production triangle question of having it good, fast, or cheap and only being able to pick 2. I always pick good and the other two usually follow because then you're not having to be distracted by rework (which costs and slows down the main vein of work). As the team practices doing it right time after time, they get better and faster and that also means a job gets done for less. I rather think of it as a "success spiral".
A lot of companies miss that by going for fast or cheap as the primary goal and end up in a "death spiral" of rework and failures.
So, to reverse the question, "Does Quality Enhance Speed"? I'd have to say yes. "Does Speed Compromise Quality"? I'd have to say "It Depends" on how the speed is achieved.
Yep. I think far, far too few people get the "practice doing it right and get better and faster" part. I see too many people stuck in patterns and being unwilling to change the way their write code, test, etc.
April 14, 2017 at 7:48 am
Steve Jones - SSC Editor - Friday, April 14, 2017 6:41 AMJeff Moden - Thursday, April 13, 2017 11:08 PMDoes Speed Compromise Quality?
Interesting question. I am reminded of the ol' production triangle question of having it good, fast, or cheap and only being able to pick 2. I always pick good and the other two usually follow because then you're not having to be distracted by rework (which costs and slows down the main vein of work). As the team practices doing it right time after time, they get better and faster and that also means a job gets done for less. I rather think of it as a "success spiral".
A lot of companies miss that by going for fast or cheap as the primary goal and end up in a "death spiral" of rework and failures.
So, to reverse the question, "Does Quality Enhance Speed"? I'd have to say yes. "Does Speed Compromise Quality"? I'd have to say "It Depends" on how the speed is achieved.
Yep. I think far, far too few people get the "practice doing it right and get better and faster" part. I see too many people stuck in patterns and being unwilling to change the way their write code, test, etc.
By the same token, I've also seen people destroy the "get it right" part by imparting a "new and faster method of doing things" and then keep using the new and "faster" way even though it's been proven that the only thing that it's really done is make it so you can deploy errors faster than ever. While certainly not true in many cases, some shops actually do need to use continuous deployment methods because it's the only way they can keep up with the rework fixes that have become necessary.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 14, 2017 at 8:06 am
Jeff Moden - Friday, April 14, 2017 7:48 AMSteve Jones - SSC Editor - Friday, April 14, 2017 6:41 AMJeff Moden - Thursday, April 13, 2017 11:08 PMDoes Speed Compromise Quality?
Interesting question. I am reminded of the ol' production triangle question of having it good, fast, or cheap and only being able to pick 2. I always pick good and the other two usually follow because then you're not having to be distracted by rework (which costs and slows down the main vein of work). As the team practices doing it right time after time, they get better and faster and that also means a job gets done for less. I rather think of it as a "success spiral".
A lot of companies miss that by going for fast or cheap as the primary goal and end up in a "death spiral" of rework and failures.
So, to reverse the question, "Does Quality Enhance Speed"? I'd have to say yes. "Does Speed Compromise Quality"? I'd have to say "It Depends" on how the speed is achieved.
Yep. I think far, far too few people get the "practice doing it right and get better and faster" part. I see too many people stuck in patterns and being unwilling to change the way their write code, test, etc.
By the same token, I've also seen people destroy the "get it right" part by imparting a "new and faster method of doing things" and then keep using the new and "faster" way even though it's been proven that the only thing that it's really done is make it so you can deploy errors faster than ever. While certainly not true in many cases, some shops actually do need to use continuous deployment methods because it's the only way they can keep up with the rework fixes that have become necessary.
The cynical part of me wonders if DevOps wasn't developed *precisely* to keep up with the constant flow of bugs the increased release cadence created... :sick:
April 14, 2017 at 9:16 am
I think it's important to note that it takes time and practice to get new techniques delivering speed and quality improvements.
You wont get it right first time. Each time you improve on what you had before until a lot of seemingly minor changes coalesce to become a huge transformation.
Lets suppose you start by getting production infrastructure dashboards on the walls where your developers work. It seems like a cosmetic change until the infrastructure guys explain the significance of the various measures. The next thing that happens is that the developers identify those measures that? their work influences. The infrastructure guys then have another instructional piece to explain how individual metrics may lead to false conclusions but specific combinations have particular significance. The developers then find ways to access the underlying metric data so they can automate stress tests etc.
Thinking of tests up front may improve the breadth of the tests from the outset but adding to tests later as a sadder, wiser developer will simply be the same destination by a longer, more painful route. At the end of it you will still have vastly more tests than you would ever run manually and executed Consistently.
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply