Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Move Slow and Make Things

multithreaded.stitchfix.com

Post reply on HN
Print view View original

121–130 of 133 posts

Re: Move Slow and Make Things

#121

Post by exabrial »

The fact they think that individual customizations of clothing is a joke, when that's exactly what they advertise, says a lot about the company. You're just cattle, and they think it's hilarious you're actually falling for their marketing wank.

I'd _highly_ recommend M-Tailor however as an alternative. It's not a subscription box, but the clothes are extremely well made and the "body scanning" technology actually works (especially for someone of an odd body size like myself: 6'5", 205lbs, athletic build).

Another good company, but I don't know much about other than they're based in Southeast Asia is iTailor. They'll build you -exactly- what you want, to a fault in my experience. Get measured professionally by someone with experience if you're going this route.

Re: Move Slow and Make Things

#122

Post by NateEag »

ChrisMarshallNY wrote: post #120
NateEag wrote: post #113

Earlier quoted context omitted.

To prevent a prototype or proof of concept from shipping, you need to leave it feature-incomplete. The mistake people often make with such things is building it thoroughly enough that it can be shipped. If you hit that problem, you didn't build a proof of concept - you built sloppy production code.

Good point, but I have found that just doing it right the first time works for me. In fact, I'm doing it right now. In the Xcode window, I'm building a test release that the team will run and review for usability issues and bugs. If they find any bugs or issues, I fix/address them before moving on to the next function implementation. The significant advantage that this confers, is that the app is constantly in "relea…

Perfectly reasonable workflow.

I lean towards POCs these days because I have experienced the requirements turning out to be all wrong far too often. It's hard for people to know what they want or need before they can try something sort of real.

Re: Move Slow and Make Things

#123

Post by hardsoftnfloppy »

Stitch Fix is trash, their clothes are no name slave made, they never have anything in stock for the "stylists" to actually ship to customers.

Their "AI" that they're trying to sell, seriously suggests parkas to people in Florida like climates... AND WORSE... LOCK THE "STYLISTS" TO NOT BE ABLE TO SELECT OTHER OPTIONS TO SEND...

They never stfu about diversity, and their entire engineering team is white and asian dudes.

Re: Move Slow and Make Things

#124

Post by nicbou »

bovermyer wrote: post #65

My thoughts on this were a little too long for a comment, so I posted them on my blog: https://benovermyer.com/blog/building-things-slowly/

Just a heads up: your website does not render properly on mobile (Firefox for Android). The page is much wider than the screen, but zooming out is not possible.

Re: Move Slow and Make Things

#125

Post by nicbou »

lmarcos wrote: post #41

On a more serious tone: what would take to the IT industry to switch from "move fast and get shit done" to "move slow and make things'? Geninuosly asking. If it becomes a thing, it would only be because the developers push it further... and HN is full of devs. I doubt such a perspective would ever come from "lean" managers and the like.

A generous amount of free time.

I move slow and make things because my livelihood doesn't depend on it. I have practically unlimited free time and sufficient income, so I can build things that don't matter.

This isn't the case for more people. Time is money, and being slow means you're not earning much for your time.

Re: Move Slow and Make Things

#126

Post by bovermyer »

nicbou wrote: post #124
bovermyer wrote: post #65

My thoughts on this were a little too long for a comment, so I posted them on my blog: https://benovermyer.com/blog/building-things-slowly/

Just a heads up: your website does not render properly on mobile (Firefox for Android). The page is much wider than the screen, but zooming out is not possible.

Thanks for that, I'll look into it.

Re: Move Slow and Make Things

#127

Post by LandR »

NateEag wrote: post #122
ChrisMarshallNY wrote: post #120

Earlier quoted context omitted.

Good point, but I have found that just doing it right the first time works for me. In fact, I'm doing it right now. In the Xcode window, I'm building a test release that the team will run and review for usability issues and bugs. If they find any bugs or issues, I fix/address them before moving on to the next function implementation. The significant advantage that this confers, is that the app is constantly in "relea…

Perfectly reasonable workflow. I lean towards POCs these days because I have experienced the requirements turning out to be all wrong far too often. It's hard for people to know what they want or need before they can try something sort of real.

The problem i have is I get told to write a fast proof of concept. I make it clear that its hacky, poor quality code. Then ill be told to make it live to test it.

Then it ends up in production. Then they want to add stuff to it, which is a nightmare as the code is terrible.

Every time.

Re: Move Slow and Make Things

#128

Post by ChrisMarshallNY »

LandR wrote: post #127
NateEag wrote: post #122

Earlier quoted context omitted.

Perfectly reasonable workflow. I lean towards POCs these days because I have experienced the requirements turning out to be all wrong far too often. It's hard for people to know what they want or need before they can try something sort of real.

The problem i have is I get told to write a fast proof of concept. I make it clear that its hacky, poor quality code. Then ill be told to make it live to test it. Then it ends up in production. Then they want to add stuff to it, which is a nightmare as the code is terrible. Every time.

Yup. My experience, as well.

That's exactly why I work like I do, now.

Unfortunately, I can't do it when I'm working for anyone else. They never let me do it the way that I do it. I have to be doing it on my own.

It works. It really works, if I write top-quality code, the whole time; even if I have to throw away or drastically refactor/write production-quality code.

My experience is that the final product:

1) Is of almost jaw-dropping quality (it was tested thoroughly, the entire time),

2) Is tailored exactly to the needs of the end-user (which deviated substantially from their original requirements), and

3) Arrives very, very quickly (this always surprises people).

Re: Move Slow and Make Things

#129

Post by NateEag »

LandR wrote: post #127
NateEag wrote: post #122

Earlier quoted context omitted.

Perfectly reasonable workflow. I lean towards POCs these days because I have experienced the requirements turning out to be all wrong far too often. It's hard for people to know what they want or need before they can try something sort of real.

The problem i have is I get told to write a fast proof of concept. I make it clear that its hacky, poor quality code. Then ill be told to make it live to test it. Then it ends up in production. Then they want to add stuff to it, which is a nightmare as the code is terrible. Every time.

I'm sorry. That sounds miserable. :(

Like I said - a proof of concept is only a POC if major features and plumbing are just missing.

You only build the parts you need to show the concept is possible. The bits you don't know exactly how to do already.

If it can be pushed to production usefully, it's too full-featured to call a POC, in my view.

Re: Move Slow and Make Things

#130

Post by hakfoo »

solarmist wrote: post #3

I’m sad this is an April fools joke because a lot of the sentiment rings true and I love the slogan “move slow and make things.” Artisans make beautiful things and software artisans make beautiful software, but it’s hard to do it and still be a viable business. And artisans moving slowly isn’t arbitrary. They move slow on the things that matter. The things that shine when attention was paid to the details.

I've wondered if the software space has been able to get away with "move fast and break things" because liability and regulation haven't caught up with it.

At some point, we started expecting civil and mechanical engineers to stop "moving fast and breaking things." If software engineers were similar licensed and on the hook for signing off on garbage, we'd see a dramatic slowdown of the pace of development, but likely an uptick in quality.

I could imagine it one day even being a bifurcation of the industry. You want to work on cat videos, you can be a non-licensed programmer. You want to work on medical devices or core financial-backbone things? Better be a full-certified Software Engineer.

Post reply on HN