5 ms·

"Move fast and break things"--said no carpenter, ever. Imagine if doctors, engineers, plumbers, electricians, and all the other real world folks we depend on d

"Move fast and break things"--said no carpenter, ever. Imagine if doctors, engineers, plumbers, electricians, and all the other real world folks we depend on decided this was a good way to operate. Would you drive across a bridge knowing that was the motto of the people who designed and built it?

tmcb 7y ago
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.
- mdorazio 7y ago
  There's a rather big difference between breaking things in a test & learning environment (all of the examples you provided) and breaking things in a production release.
  - tmcb 7y ago
    There is also a big difference between a profession that respects the intelligence of their peers and one where people assume that their peers are ignorant and lack common sense. Surgeons must act fast and be good at multitasking. I bet they are not in a forum discussing if those traits make them vulnerable to hasty decisions and to loss of concentration on the task at hand.
    - mdorazio 7y ago
      I'm genuinely not sure what your point is. Can you explain it? The two surgeons I know generally have extreme trust that their tools, monitors, etc. will "just work" when and where they are needed, every time, and that those things have been properly vetted by the medical industry and community prior to going into a live hospital environment unless it's specifically known that they are testing something new.
      - tmcb 7y ago
        It is an analogy. I will move on to another one. Competent developers, on the other hand, have extreme trust on the judgment of their peers. They know they won't break the production build at will; if they ever do, they will use all information gathered to improve the team's infrastructure and their own development process. They are not afraid of using the term, because breaking things is the most valuable thing that you can do for your learning, but, most importantly, they realize that other people's lives and goods are potentially at stake, and act with due diligence. So, "break things" is not an excuse to break the production build at will and move on to the next task. If competent developers ever find themselves in a team that does so, they try to educate the team and, if that does not work, GTFO.
- Finnucane 7y ago
  Right, because who cares if it's broken crap as long as it's generating revenue.
  - tmcb 7y ago
    This sarcastic remark is entirely misguided. Broken crap does not generate revenue; working code does. But, oftentimes, no code is as effective as broken code, and takes longer to fix. This is when you should use your judgment. “Break things” is not the same as committing faulty code, it just means that validating some of your hypotheses in a controlled environment may have a higher cost. Just to make things clearer, I am a programmer myself, and have never been in a management position before. My overall impression is that I learn faster when I make mistakes and need to fix them. Expecting otherwise would contradict most of the experts on human learning.
  - scarejunba 7y ago
    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.
mrlala 7y ago
>"Move fast and break things"--said no carpenter, ever. Worst analogy ever. If we had GIT for woodworking you would see productivity skyrocket. But you can't restore wood like that. You can't restore pipes, wires, structures like that. Code.. you can. So get out of here with your analogy. I can move at a very fast paced coding new ideas at times, or implementing random stuff knowing I will probably break stuff. But you know what? I can fix that afterwards. It doesn't matter that I broke something to get something else to work.
- DoofusOfDeath 7y ago
  I think the carpenter analogy is actually very good: it gives us a starting point for thinking about where MFABT is / isn't a good idea.
- Finnucane 7y ago
  And do you make your users suffer your broken stuff?
- mrkeen 7y ago
  Can you fix data?
- jmhnilbog 7y ago
  Reverting won't erase your users' poor experience with your product.
mark-r 7y ago
"Measure twice, cut once" I think is the saying carpenters use.
- sixstringtheory 7y ago
  And the version most pertinent to us developers: "Weeks of coding can save you hours of planning."
  - collyw 7y ago
    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.
    - tmcb 7y ago
      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.
      - sixstringtheory 7y ago
        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...
collyw 7y ago
I agree with you on this but just as a counter point about Doctors. Someone on here a few months back speculated that the reason a lot of the top doctors in the US were from India is because they basically got the chance to "break a few things" back home before they got to the States. As such they got valuable learning experience that would not be possible with the stricter regulations in the US.

tmcb 7y ago

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.

mdorazio 7y ago
There's a rather big difference between breaking things in a test & learning environment (all of the examples you provided) and breaking things in a production release.
- tmcb 7y ago
  There is also a big difference between a profession that respects the intelligence of their peers and one where people assume that their peers are ignorant and lack common sense. Surgeons must act fast and be good at multitasking. I bet they are not in a forum discussing if those traits make them vulnerable to hasty decisions and to loss of concentration on the task at hand.
  - mdorazio 7y ago
    I'm genuinely not sure what your point is. Can you explain it? The two surgeons I know generally have extreme trust that their tools, monitors, etc. will "just work" when and where they are needed, every time, and that those things have been properly vetted by the medical industry and community prior to going into a live hospital environment unless it's specifically known that they are testing something new.
    - tmcb 7y ago
      It is an analogy. I will move on to another one. Competent developers, on the other hand, have extreme trust on the judgment of their peers. They know they won't break the production build at will; if they ever do, they will use all information gathered to improve the team's infrastructure and their own development process. They are not afraid of using the term, because breaking things is the most valuable thing that you can do for your learning, but, most importantly, they realize that other people's lives and goods are potentially at stake, and act with due diligence. So, "break things" is not an excuse to break the production build at will and move on to the next task. If competent developers ever find themselves in a team that does so, they try to educate the team and, if that does not work, GTFO.
Finnucane 7y ago
Right, because who cares if it's broken crap as long as it's generating revenue.
- tmcb 7y ago
  This sarcastic remark is entirely misguided. Broken crap does not generate revenue; working code does. But, oftentimes, no code is as effective as broken code, and takes longer to fix. This is when you should use your judgment. “Break things” is not the same as committing faulty code, it just means that validating some of your hypotheses in a controlled environment may have a higher cost. Just to make things clearer, I am a programmer myself, and have never been in a management position before. My overall impression is that I learn faster when I make mistakes and need to fix them. Expecting otherwise would contradict most of the experts on human learning.
- scarejunba 7y ago
  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.

mrlala 7y ago

>"Move fast and break things"--said no carpenter, ever. Worst analogy ever. If we had GIT for woodworking you would see productivity skyrocket. But you can't restore wood like that. You can't restore pipes, wires, structures like that. Code.. you can. So get out of here with your analogy. I can move at a very fast paced coding new ideas at times, or implementing random stuff knowing I will probably break stuff. But you know what? I can fix that afterwards. It doesn't matter that I broke something to get something else to work.

DoofusOfDeath 7y ago
I think the carpenter analogy is actually very good: it gives us a starting point for thinking about where MFABT is / isn't a good idea.
Finnucane 7y ago
And do you make your users suffer your broken stuff?
mrkeen 7y ago
Can you fix data?
jmhnilbog 7y ago
Reverting won't erase your users' poor experience with your product.

mark-r 7y ago

"Measure twice, cut once" I think is the saying carpenters use.

sixstringtheory 7y ago
And the version most pertinent to us developers: "Weeks of coding can save you hours of planning."
- collyw 7y ago
  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.
  - tmcb 7y ago
    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.
    - sixstringtheory 7y ago
      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...

collyw 7y ago

I agree with you on this but just as a counter point about Doctors. Someone on here a few months back speculated that the reason a lot of the top doctors in the US were from India is because they basically got the chance to "break a few things" back home before they got to the States. As such they got valuable learning experience that would not be possible with the stricter regulations in the US.