Earlier quoted context omitted.
"Measure twice, cut once" I think is the saying carpenters use.
And the version most pertinent to us developers: "Weeks of coding can save you hours of planning."
[deleted]
The Fallacy of Move Fast and Break Things
81–90 of 99 posts
Re: The Fallacy of Move Fast and Break Things
#82Earlier quoted context omitted.
There is an important distinction between MFABT and these other examples. In all of the other examples, the consequences of breaking accrue to the person making the decision to break things. People make better decisions about the risks to take when they have to deal with the consequences. With MFABT the party doing the breaking isn’t often the one suffering from the breakage and that drastically changes the system dy…
>In all of the other examples, the consequences of breaking accrue to the person making the decision to break things. If a fishing ship goes out to sea and fails to catch enough fish or is wrecked because of a storm, it affects the families of the crew and everyone else who depended on them. If Michael Jordan fails and misses the game-winning shot, it affects his whole team . If it's losing a playoff elimination game…
I can confirm that I saw the phrase on posters visiting the Palo Alto site in 2011.
Re: The Fallacy of Move Fast and Break Things
#83Earlier quoted context omitted.
And the version most pertinent to us developers: "Weeks of coding can save you hours of planning."
I wish more developers would follow this advice. I think I am the only person I know that draws diagrams with pen and paper before typing out code to clarify my though process. Occasionally we get some whiteboard high level stuff with some boxes and lots of arrows but that's about it.
I usually don’t draw diagrams, but my mind works better with what I usually call “tiny examples”: working code unrelated to the main codebase. Most of the time I have pen and paper with me, but I never do anything fancy with it. The advantage of that is most of the times, when I’m done, I need only to copy the example to the actual codebase with small changes.
This process helps me in so many different ways, and seems so productive, but I’ve never found anybody that uses such an approach. I would love to discuss it further with other people so that I can improve it.
Re: The Fallacy of Move Fast and Break Things
#84The "move fast and break things" is just a web app version of previous sayings in other domains: - "A ship in harbor is safe but that's not what ships are made for." - "If I've made more shots than you, it's because I've _missed_ more shots than you." -- variations of this from Michael Jordan, Wayne Gretzky, other athletes - "All great writers got better by writing a lot of _bad_ sentences." - "If you want to learn h…
Subtly but importantly: it's only OK to break your own things. People hate it coming from Facebook because they hold the world's most powerful trove of personal information, and a reccommendation engine that gets to nudge what a lot of people think is important. Similarly self-driving cars.
That's your personal restriction on MFABT but Facebook MFABT is most definitely "bias towards speed". It has no "don't break other people's things" in it. And they behave like that. Correctly, in my opinion. Even if I've been at the receiving end having to implement against their Marketing API (which once released a 2-week deprecation notice).
Re: The Fallacy of Move Fast and Break Things
#85Earlier quoted context omitted.
Thing is, they do, but not in the ways you would expect. Cadavers on medical schools. Wind tunnel modeling. Computer-aided designs. The main difference to those is that the software industry can indulge on testing its own assets with little to no cost, and especially if that does not impact your ability to generate revenue.
Right, because who cares if it's broken crap as long as it's generating revenue.
Actually, exactly. I'm in the business of writing software that's useful to people. The way they tell me it's useful to them is by paying me. At any point you may determine it isn't useful to you. Just don't pay me.
Re: The Fallacy of Move Fast and Break Things
#86Lot of answers so far seem to have missed the points being made in the book the article references. If you have the ability to ship things fast - and so do regularly - you will find that your releases: - Have a small blast radius if there are bugs, because how much blast can you have in an hour's work versus a quarter's? - The tooling that you build to let you go fast will tell you that a blast is indeed happening ri…
What are LEST metrics? I couldn't seem to find anything from Google and now it feels like I'm missing some major concept
Latency, Error rate, Saturation (think: request queue depth), and Throughput. They are the “Golden Signals” in Site Reliability Engineering (SRE).
Re: The Fallacy of Move Fast and Break Things
#87Earlier quoted context omitted.
`sudo rm -rf /` is a very big thing to do in a very small amount of code, sure. I'd adovocate thinking about probabilities then: If you have a shorter period of time to produce a smaller change, are you more or less likely to have a smaller blast radius than if you have a longer period of time to produce a much larger change? There are no absolutes, but we're talking about risk here, and risk is about impact and _lik…
I’d say that change duration is irrelevant to blast radius, because bug impact is independent of code size. Having said that - a smaller piece of code is easier to understand, so there is more potential to notice problems. However that depends on whether you do that diligence. And the dangerously false belief that the blast radius is going to be smaller because of change size rather than understanding works against y…
I think blast radius is basically
bug size * mean time to recovery
So if you release early, release often and keep an eye on your metrics, you stand a good chance of your blast radius being consistently low.
You won’t eliminate it, you’ll just be beating the team with rare and large releases that take an age to get through their release process.
Of course, if you can take your time and make small changes slowly, but release them quickly, you’re now doing even better, but there are few businesses where that’s economically viable: competitors will just get to product market fit quicker than you will.
Re: The Fallacy of Move Fast and Break Things
#88Earlier quoted context omitted.
I wish more developers would follow this advice. I think I am the only person I know that draws diagrams with pen and paper before typing out code to clarify my though process. Occasionally we get some whiteboard high level stuff with some boxes and lots of arrows but that's about it.
I usually don’t draw diagrams, but my mind works better with what I usually call “tiny examples”: working code unrelated to the main codebase. Most of the time I have pen and paper with me, but I never do anything fancy with it. The advantage of that is most of the times, when I’m done, I need only to copy the example to the actual codebase with small changes. This process helps me in so many different ways, and seem…
One of my colleagues has an emacs flow to quickly land him in a new “experiment” project. He’s on backend, and I’m on iOS. I’ve used Swift Playgrounds for iOS a few times which is nice, but I never liked Xcode playgrounds as much. Most often I’ll just create a new test case in an app’s unit testing suite to do my experiment. This doesn’t work as well for UI experimentation, though. Usually I iterate right on the actual UI of my app, but it could definitely be worthwhile doing a simpler thing on its own before moving into the full-fledged existing UI. Certainly would help when filing a bug with Apple when they ask for a sample project...
Re: The Fallacy of Move Fast and Break Things
#89It's a matter of knowing your audience and knowing your funder's/owner's goals and expected risk-reward trade-off profile.
A "cowboy" mentality may indeed help a start-up edge out competitors. But applying that to an established company can ruin your reputation: you have more to lose by playing fast and loose. Startups by nature are a gamble, but if an established corporation gambles too often they may poke a hole in their dam that they can't patch fast enough.
Venture capitalists usually factor in a high failure rate to startups they invest in. Their plan is that enough will succeed in a big way to counter the high failure rate.
A lot of "fads gone wrong" happen when a technique or technology that works for one situation or size is misapplied to another. Your office printer inventory tracker doesn't need microservices and web-scale databases.
Pilot projects with new technology is often a good thing, but don't bet key organizational functions on such a project (sometimes called line-of-business systems).
Re: The Fallacy of Move Fast and Break Things
#90Earlier quoted context omitted.
And the version most pertinent to us developers: "Weeks of coding can save you hours of planning."
I wish more developers would follow this advice. I think I am the only person I know that draws diagrams with pen and paper before typing out code to clarify my though process. Occasionally we get some whiteboard high level stuff with some boxes and lots of arrows but that's about it.
One of my most successful development experiences came from starting not with code, but with a keynote/powerpoint slide deck. It made me think through exactly what it was I was trying to achieve, what it would involve, and how it would work. When I realized something or other didn't work well, changing approaches only required editing a few high-level diagrams. Computer diagrams can be cumbersome compared to pen and paper, but have the great advantage of being easy to change once you've spent the time to draw them. Implementing the final solution was much easier when I could look back on how it was supposed to work. And at the end, I already had slides ready to explain everything...