Move Slow and Make Things
multithreaded.stitchfix.com
multithreaded.stitchfix.com
I recently ordered a custom tailored set of shirt, trousers, and belt. Their site was bragging about their great AI technology, but sadly I didn't notice that red flag early enough.
The results were nothing short of disastrous. I sent in my measurements and they sent me a trouser with wrong measurements and a postcard that said that they adjusted my measurements with AI for a better fit. The belt they included was a completely different size than the trouser and I'm still waiting for the shirt to arrive. And now I'm fighting the usual uphill battle to talk to a human and get this mess fixed or get a refund.
The core of Stitchfix is personalization, as they say. But that means an individual solution for each individual customer, and not AI for memorizing generic trends in a huge dataset.
That is nothing short of hilarious. The machine knows best! Who are you, human, to pretend you are able to measure yourself?!
> AI for memorizing generic trends
It's possible "AI" may be just a pretext to sell mass-made junk and pretend it is adjusted to each individual.
It's also an internal distraction. They'd achieve something much closer to what they promise if they just threw some old-school regression analysis at the problem. But that's not cool these days, plus it's hard to relabel as AI even for the marketroids these days, and would involve actual work :).
This applies to many "AI companies" - so many want to either have easy process (throw data at some random Kaggle model and hope it sticks) or just a buzzword to bullshit investors with. Sometimes both.
Talk about distraction...
And by "neural network", I mean my brain.
And by "thousands of fashion trends ", I mean I look at people in the mall.
Maybe it could be considered class of fallacy, a kind that one would say the most popular choice of integers between 1 and 2 is 1.5000001.
Was excited to see how the pants and shirts fit (on the site it looked awesome, but then the actual user reviews on some were so bad lol)
Also, the founder is the Japanese guy going to the moon.
A lot of people do not in fact know how to measure themselves properly for clothes (many people measure the wrong part of their body for the "waist"). Perhaps even more people think they're a certain size, but have never actually measured themselves, they just go by the measurements on clothes they already own, which are frequently "vanity sized" to make people feel better. I don't envy solving this problem between two sets of users: people who actually have the correct measurements and people who believe strongly that they do, but are quite wrong. Imagine how far off you would be if you went by your Old Navy pants: https://flowingdata.com/2010/09/30/advertised-vs-actual-wais...
The size of the clothes also need to account for the fabric type. If it stretches x%, then you’ll want to maybe make it smaller, so it stretches to fit, or it will look frumpy. If the fabric doesn’t stretch at all, you’ll need to make sure there’s enough ease in the garment so you can bend and move your arms naturally.
"I, For One, Welcome Our Robot Overlords"
into the comments field when ordering :)
> It's possible "AI" may be just a pretext to sell mass-made junk and pretend it is adjusted to each individual.
Actually, I wouldn't mind that too much. It is difficult for me to find well-fitting trousers, so if they can supply those for me, I'm happy as long as the quality is acceptable. Plus their price is roughly half of what a proper tailor would cost me, so I kind of expected them to cut some corners.
This brings a whole new meaning to "over fitting"
It may very well be to my own detriment (there is a lot of promise in either) but fortunately there are lots of interesting problems outside these areas and I can just treat the mention of either of those topics as red flags.
That said, I want to note that I have had good results with Stitchfix but that was due to entering professionally-taken measurements. I got even better results however, from a local to-order suit maker and bought the full suit there, but basic shirt(s) from Stitchfix
And yes, my measurements were also from a professional tailor. But the resulting trouser has (among other issues) been "corrected" to a 15cm shorter outside leg length, so I wonder if a professional vs. an amateur measuring it would have made much of a difference.
I'll take my VC money now, please.
Whoa.
customer: Please, I need a trouser size 34"
AI: Thank you sir, but according to my data, a 33" will better suit you
It's WFH time now though, I'm wearing 2/3XL shirts (good cut though, they don't look baggy) and pajama pants and have done so for over a year now. I am here for the comfort.
I'm trying to think of a way this makes sense. Do they have access to some big database about you that they can use to predict how you'll screw up your measurements?
;laskdfjls;adkfasd;lfj
You don't have any way to know which of the measurements is wrong.
You don't know what correction to apply. The best you can do is shrink along one or more of the dimensions in the direction of a mean of something, which may or may not be relevant to that customer. In return you intentionally mess up the orders of many customers, wasting their time in the process.
I kind of get where they are coming from, though. I myself also love over-engineering solutions ^_^
Cool, what they mean is they probably have some (barely) linear fits of people to some dimension, but of course that breaks down quick as the USAF found out in the 40s https://www.thestar.com/news/insight/2016/01/16/when-us-air-...
I switched to Bombfell and I had been very happy until my cancellation.(canceled cause I wanted to explore fashion myself)
- Bill Vaughan (https://quoteinvestigator.com/2010/12/07/foul-computer)
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 have started making this sort of software, and I thoroughly enjoy it. I target the platform I use, I solve the problems I have, and my only metric is pleasure.
I wish we all had more of such projects.
I wouldn't have been able to put so much work in maintaining ArchMac for so long without going completely bonkers had I not taken it this way either.
So it’s entirely possible to build large scale projects this way, and I’m wondering how we could make companies work that way too. At the very least it should be part of any employee sustainability plan.
“When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”
Obviously, this is totally incompatible with how most software is made in the industry, so I just do it as a hobby instead.
What's missing from my extremely simplified model?
I chose to take this April’s fool that way.
I "move slow and make things" in some sense. I will endeavor to use this as a jumping off point for something constructive rather than leaving a pointless whiney comment about how the world will never understand or appreciate me.
I would love to see “small batch data science” where people actually understand the results. Black box recommendations never feel really right.
In general, if your DS's can't explain the model then something has gone horribly wrong.
For example, there's been plenty of issues like racial bias with the computer vision algorithms that police uses, which effectively is data science on pictures. But nobody knows why the issue occurs and nobody can specifically fix it without the risk of breaking a thousand unrelated other things.
Sure we do. Photography itself has a racial bias. [0] Different skin tones produce different levels of detail, and it has been an uphill battle to be able to capture those details since the advent of photography.
So long as facial recognition relies on photography, and photography is flawed, then every dataset is biased. Which will exacerbate the bias of the AI, which already has its own set of problems from where those datasets are formed.
[0] https://www.nytimes.com/2019/04/25/lens/sarah-lewis-racial-b...
They do know why that occurs. It's because the data set is biased.
edit: And a statistical analysis isn't some sort of magic data genie. Statistics can give rigorous results because it makes strong assumptions. If those assumptions don't hold then the results aren't rigorous anymore. A trillion parameters model can pull interactions out of your data that almost no statistical analysis of the data would identify ahead of time. So what you need to analyze is the model and try to infer why it's predicting different certain results and then work backwards from there.
Second: even if you do, you're going to have a hard time controlling for the fact that the police and criminal justice system has a long history of disproportionately enforcing the law against people of color. The base data about who commits crimes, gets convicted, etc. for well over a hundred years is going to reflect this bias.
I'm not claiming to have done my homework here either, same disclaimer applies. I suspect you could find somebody who does study this if you wanted to look.
All of the above assumes we're discussing the US, btw.
Too bad I wasn't a data scientist or else I could just get a passing grade by claiming the questions were chosen from a biased data set, or retake the exam until the data set matched the questions I studied for, at which point the data set would no longer be biased, lol.
Funny line of work, this data 'science' where you only use the results that fit the narrative you wanted in the first place.
We're in full doublethink mode, just keep repeating data 'science', 'science', 'science'. :)
With modern ML models data scientists can generally explain why the model should work but not exactly how it gives any specific prediction. Explaining how a model with a trillion parameters comes up with an answer is not a trivial task.
As an aside, this is a hilarious phrasing. What are we going to call these methods in a decade? You'd probably be better off phrasing it as deep neural networks.
Anyway, this is not really true. There are methods (for lots see: https://christophm.github.io/interpretable-ml-book/) and the DeepDream paper came out in 2015, so it's possible.
It's computationally expensive, and a lot of people don't see the value, but my argument is that if you want to use the model in the real world, and have non-technical stakeholders then you'll need to do this, and in general, I've found it to be the best way to actually improve a model.
And to be fair, if you just need to see how the predictions vary as a function of the inputs, you can again hold all but one constant and run a bunch of different values through the model.
Again, this can all be done, but I think it's more a question of will than capability (and hence the context of my original commment).
I phrased it the way I did for a reason. Large Random Forrest models are also not easily interpretable. Even large logistic regression models with feature interactions and feature hashing aren't easily interpretable. It's not a question of the model technique used but rather the amount of parameters and how many feature interactions are modeled.
>And to be fair, if you just need to see how the predictions vary as a function of the inputs, you can again hold all but one constant and run a bunch of different values through the model.
This only provides a partial view of the feature impact due to non-linear interactions.
I've been calling it my "curiosity killed the cat" spreadsheet. Small batch data science sounds so much more respectable while meaning basically the same thing, I think.
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.
It's not that hard actually, but you must limit growth. You can easily be profitable and make an amazing product if your goal is not $1B in revenue, but just to be profitable at a small scale, which allows you to run things at your own pace.
And then making things. To me this means no paper prototyping. Not selling people on your idea without having anything tangible. Some may call it smart. To me it feels like gambling with your believability / integrity. There are only so many times you can do this before people get tired of you and your stories / dreams / business ideas. Just make something, show it to people when it’s actually useful. And feel good about actually having made something people liked. Instead of selling something people liked and then suffer the feeling of non-stop pressure, constantly _not_ being where you’ve told others you are.
Happy april fools :)
> There once was a Master Programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the Master to evaluate his progress, the Master criticized him for writing unstructured programs, saying, "What is appropriate for the Master is not appropriate for the novice. You must understand Tao before transcending structure."
~~The Tao of Programming
For example, I have https://www.invisible-computers.com up as a website. You can read about the product and you can sign up to be notified. But I won't take a cent until I have a product ready to ship.
But when someone does agree to pay (meaning you've somewhat validated your idea) then you're left empty handed and have to backtrack with your first customer. Not a great start. But that's just me :) YMMV
Of course a newsletter signup is not a sale. Not even 1%. But it’s still a signal.
And selling something you don’t have is borderline fraud in my book. Even if you backtrack and refund, it was still a lie and a waste of the customer’s time.
Also if one is selling something one should be aware that now you will have to support it for the next 10 years, even if it turns out to be an unprofitable business.
1. Why "Invisible"?
2. Why such a thick frame? I hope you expand frame choices, or offer a minimal version that customer can frame.
3. I guess you are building a custom UI layout for the calendar data, but please allow any URL to be loaded in the frame, so the community can build custom data views.
I “move slow,” taking the time to test carefully, and leave clean, concise, well-documented code, but I’m told that I actually move at a blistering pace.
I have found there is absolutely no substitute for having an operational, full-feature implementation (I hesitate to call it a “prototype,” because it needs to be fully functional, not just eye candy). I am not a fan of lash-up prototypes, because they invariably become ship code, and starting on a foundation of sand is a very, very bad idea. I short-circuit that, by writing everything as ship code; even my A/B experiments. I can often recycle the rejected code for other projects. It also saves a lot of testing time, as the code is being constantly tested from the start, and being tested while still in scaffolding (meaning more complete testing, overall).
For example, in the app I’m developing now, I’m working on a dropdown screen that allows the user to define search criteria for a database lookup. It’s a complex and fraught operation, and I’ve already had to make a number of changes, based on actually using the facility, as opposed to thinking about using it. If I had simply solidified my original design, it would have been a mess.
I will also be making sure that the facility works for different regions and languages, despite the first implementation being only for the US. It has been my experience that this kind of thing should be built in from the start, as retrofitting it is a nightmare (and bug farm).
My approach does mean that I often need to rewrite a lot of finished, tested code, or throw out big chunks (which is one reason I have a bunch of small, polished, standalone package projects). It’s taught me to design and implement very flexible code (which is actually dangerous, so I often go back, and remove flexibility, once I have settled on an implementation). Nevertheless, I have found it’s the best way to end up with a usable, relevant, high-quality, finished product, that meets the customer’s needs, in a remarkably short time.
DISCLAIMER: This is a viable way to design UX (the kind of code I usually write), but may not be the best approach for “engine” or algorithm code.
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.
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 "release-ready" form; although incomplete.
Useful, for when we want to ask people to give us money. We just get an NDA, loop them into the TestFlight group, and let them have at it. No need for chaperones from Marketing, or sacrifices to the demo gods.
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.
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.
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.
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).
Their watch, and next the car - will be the next arguably iconic products.
The 'move slow an make things' movement is a much-needed niche to be explored, and a place where I'd love to be.
"slow is smooth and smooth is fast" is something that I'm working to internalize.
This is why I believe, at core, in 100% test coverage.
For a tech business, "move slow and make things" can only be a joke. But for a developer collective, it can be real.
This is GHC / Haskell philosophy. Golang tries too.
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.
As others have mused here and I'll join them: we can use a lot more hand-crafted and "slow" approach. We're chasing our own tails -- ESPECIALLY in programming! -- and progress is nearly non-existent.
I mean, in 2021, people are still debugging multithreaded shared state problems. These should belong to the past -- make it impossible on a hardware level as a start, then the programming languages will adapt in a matter of a few months at the maximum.
It should also be hardware-assisted (if it's impossible to stop it at the hardware level). Stuff like atomic counters were a good first step but the state of the art there hasn't moved in a long time (we don't have atomic 512-bit update operations, do we? if we did, a lot of kernel data structures could be atomically updated; this alone would fix a lot of contention problems).
The hardware can also just work in a CRDT/OT-like manner, namely accumulate update requests for a memory location in small queues (that get flushed after 10 nanoseconds or after the mini queue fills up). This could help with a good chunk of the buggy scenarios as well.
Not saying we can make it perfect tomorrow -- of course we can't. What I am saying is that nobody [who can truly make a difference] is even trying.
It gets a bit disappointing and grim after you have been in the profession for a while, you know?
They are an improvement, absolutely, but not a big one.
I get where you’re coming from but that line of thinking got us into that mess in the first place IMO. At one point we should draw a line. Which we still don’t.
The article itself is excellent. But the best part is the title is a so much better real credo than the "real" one it parodies.
Every log structure is analyzed by hand. Every log structure data behaviour is verified with statistics by hand. Every log data is normalized by hand. Every parser is done by hand. Every log is documented and gets unit tests.
What has not gone through this process ends up in the "automatic extraction" bucket waiting to get human love.
April's fool or not, you may laugh at me. My L3 security analysts don't.
The slogan is pure gold.
"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.
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.
It's just that the current way of doing things is financially incentivized.
This part is about when i started dying laughing at every sentence, before i was a bit confused. But only after checking the comments did i realize it was on 1 april.