Hacker News Reader

Comment by Finnucane | Hacker News Reader

"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?

View on HN

>"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.

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.

Reverting won't erase your users' poor experience with your product.

And do you make your users suffer your broken stuff?

Can you fix data?

"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."

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...

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.

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...

Isn't that the entire premise of the Agile method?

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.

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.

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.

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.

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.

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.

Right, because who cares if it's broken crap as long as it's generating revenue.

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.

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.

Reply on news.ycombinator.com