Break Things !== Move Fast
-
I'm basing that on my experience contracting there ~ 1.5 years ago. They've added new control systems to address things like the GDPR, but they are all still designed to be fully productized parts of their developer framework so that developers don't have to think about them and can still move just as fast with product / feature development.
And while their product market had a little bit to do with it, they quite frankly have buggy software in production for less time than most major SAAS vendors or contract built systems.
As you noticed, they have had a quality assurance structure for way longer than 2 years. They've had it for close to 20 years now.
When they used to have this philosophy, they did always have something broken on their site, and go out of air once in a while. And they did benefit greatly from the speed they got from it, for a while, until it started being harmful.
-
The boss wanted me to find savings, so I started unplugging servers.
Isn't that what Elon did when he bought Twitter? Just randomly started unplugging shit?
-
This post did not contain any content.
At work we have the following quote on the fridge
"A ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”. Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay."
We are a software development company and my reply to this was basically that pot making hasn't changed in a long time, it's basically shaping and firing clay. Software development is comparatively new and has a vastly more dynamic landscape.
Also, the comparison is stupid because we don't write code, realize it was shit and write a new one. If we did business like that, we wouldn't be in business.
-
This post did not contain any content.
Move intentionally and fix things.
-
It’s fine to do that if you’re pre-customer and you’re just dabbling with a new idea. Once you are ready to go public though you need to be stable and secure. The big problem is when people try to apply the same development philosophy between established software and pre-alpha software.
I agree. It heavily depends on the "things" you're breaking
If it's prod, that's bad
If it's your "fuck-around" branch, go for it
-
At work we have the following quote on the fridge
"A ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”. Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay."
We are a software development company and my reply to this was basically that pot making hasn't changed in a long time, it's basically shaping and firing clay. Software development is comparatively new and has a vastly more dynamic landscape.
Also, the comparison is stupid because we don't write code, realize it was shit and write a new one. If we did business like that, we wouldn't be in business.
wrote last edited by [email protected]That's a really terrible anecdote. Real life quantity group would find ways to do less and less for the same reward. You would end up with fifty pounds of clay with a fist shape indention. Call it a pot and be done.
-
The boss wanted me to find savings, so I started unplugging servers.
But did you do it fast?
-
This post did not contain any content.
"Say that again and I'll move fast to break your face"
-
But did you do it fast?
-
At work we have the following quote on the fridge
"A ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”. Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay."
We are a software development company and my reply to this was basically that pot making hasn't changed in a long time, it's basically shaping and firing clay. Software development is comparatively new and has a vastly more dynamic landscape.
Also, the comparison is stupid because we don't write code, realize it was shit and write a new one. If we did business like that, we wouldn't be in business.
It seems like such a little story that it would probably have an origin. It doesn't seem like the ceramics class, the people who created the story mentioned, ever existed. When asked, they said it was actually a photography class (from the professor Jerry Uelsman). I'd also argue that while that may hold true for learning skills (if it does) it doesn't necessarily hold true for performing skills. Also I'd say the main reason it could work, is that it got them to actually do something.
-
This post did not contain any content.
Obligatory XKCD: https://m.xkcd.com/1428/
-
Hey Farva, what's the name of that design philosophy you like that's got all that goofy shit and no respect for established norms?
A litre of cola.
-
This post did not contain any content.
I'll break all the shit if the board of investors are the ones paying for it.
-
Once you are ready to go public though you need to be stable and secure
Is that really true though? If you have a product people actually want, they'll use it regardless of bugs
That won't be true once your competition catches up to you and your bug-riddled product is pissing off customers, pushing them towards your competitors.
-
That won't be true once your competition catches up to you and your bug-riddled product is pissing off customers, pushing them towards your competitors.
I think move fast and break things is more what you do before you get any real competition, or to get better than the competition in some areas by taking shortcuts in others.
You stop doing this when you're the big dog. Then you embrace the image of reliability and stability.
-
At work we have the following quote on the fridge
"A ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”. Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay."
We are a software development company and my reply to this was basically that pot making hasn't changed in a long time, it's basically shaping and firing clay. Software development is comparatively new and has a vastly more dynamic landscape.
Also, the comparison is stupid because we don't write code, realize it was shit and write a new one. If we did business like that, we wouldn't be in business.
That quote sounds like an excuse for mass production worship a la brave new world, lol.
-
This post did not contain any content.
Controversial opinion: I think software moving fast isn’t a good thing.
The more versions come out and the more focus there is on new features, the more half baked/abandoned the existing features become and there will be more vulnerabilities.
-
That's a really terrible anecdote. Real life quantity group would find ways to do less and less for the same reward. You would end up with fifty pounds of clay with a fist shape indention. Call it a pot and be done.
Yeah, I highly doubt it happened.
-
At work we have the following quote on the fridge
"A ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”. Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay."
We are a software development company and my reply to this was basically that pot making hasn't changed in a long time, it's basically shaping and firing clay. Software development is comparatively new and has a vastly more dynamic landscape.
Also, the comparison is stupid because we don't write code, realize it was shit and write a new one. If we did business like that, we wouldn't be in business.
wrote last edited by [email protected]Also, the comparison is stupid because we don’t write code, realize it was shit and write a new one.
I mean, you shouldn't, but it sounds like the quote-poster is asking for exactly that kind of boondoggle of a project.
-
This post did not contain any content.
I always respond with "Do you want to know if something broke? Then slow down and write tests"
