I know this is supposed to be a joke, but I feel like it's too close to reality to be funny.
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.
> 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
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.
There are two areas of technology I avoid these days -- blockchain and AI.
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
> 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
Whoa.
customer: Please, I need a trouser size 34"
AI: Thank you sir, but according to my data, a 33" will better suit you
> they adjusted my measurements with AI for a better fit
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?
One of my favourite articles on the internet is "an app can be a home-cooked meal". It's something you can make for your own enjoyment, with no plans for scaling on monetisation.
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 had a similar reaction. It's a nice April fool's joke, but I hoped for an actual counter-balance to "move fast and break things." The book that taught me the value of moving slow in programming was Test Driven Development by Kent Beck, who ironically spent several years at Facebook.
Maybe we will have a chance to move slow and make things one day, or in little moments, optimizing for the well-being of the creator etc. What rings true about it we can mull over in our heads at some point and try to implement in some parts of our lives, like hobbies, vacation, retirement, family time, etc. right?
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.
The issue is that beautiful software is invisible except in open source projects (and even then few people look under the hood). So to an end user only the UI/UX/bugs matter while everything else doesn't.
> it’s hard to do it and still be a viable business
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.
I know it’s an april fools joke. But I’ve recently “discovered” why this is nevertheless very true. If you move slow, you have a higher chance of meeting the right customer, of actually allowing your idea to grow and improve over time. Without being locked into it in one form or another. Moving slow allows you to work on it as a side project first. Which means no financial stress.
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.
> 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."
I think even when moving slow, you can still work with prototypes and get feedback as long as you're open about it and you're not taking people's money.
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.
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.
"Move slow and make things" seems like a credo for developer-run Open Source software projects. The software ships when it is ready, not when a commercial entity needs it to.
For a tech business, "move slow and make things" can only be a joke. But for a developer collective, it can be real.
It's really great to read this article: the contrast of text against the background is optimally low, it lets our eyes take its sweet time to recognize letter forms. Sit back, relax and poke your eyes out in pain. What more do readers want! Illegible, dysfunctional and decorative design is the future!
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.
I have to admit: if they didn't go overboard with hand-printed cards and carrier pigeons, I'd believe the article.
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.
This is the way I build cybersecurity opertions centers and ingest data for mining.
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.
You joke, but there's some truth to this. Better to have a nice tailored report that shows only what's needed to make a decision, than a dump from Looker, Heap, or just a 200MB of CSVs.
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.
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.
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 interesting because moving "fast" is very relative to the circumstances you're currently in. If you have an army of engineers, it's very easy to move fast (sometimes, depending on the organization) but moving fast for an individual is objectively slow in comparison.
[+] [-] fxtentacle|5 years ago|reply
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.
[+] [-] bambax|5 years ago|reply
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.
[+] [-] tomxor|5 years ago|reply
This brings a whole new meaning to "over fitting"
[+] [-] hardwaresofton|5 years ago|reply
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
[+] [-] mromanuk|5 years ago|reply
Whoa.
customer: Please, I need a trouser size 34"
AI: Thank you sir, but according to my data, a 33" will better suit you
[+] [-] bachmeier|5 years ago|reply
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?
[+] [-] murphyslab|5 years ago|reply
[+] [-] romanows|5 years ago|reply
[+] [-] raverbashing|5 years ago|reply
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-...
[+] [-] zdw|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] solarmist|5 years ago|reply
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.
[+] [-] nicbou|5 years ago|reply
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.
[+] [-] lloeki|5 years ago|reply
I chose to take this April’s fool that way.
[+] [-] jiofih|5 years ago|reply
I would love to see “small batch data science” where people actually understand the results. Black box recommendations never feel really right.
[+] [-] jkingsbery|5 years ago|reply
[+] [-] solarmist|5 years ago|reply
[+] [-] rkagerer|5 years ago|reply
[+] [-] JetAlone|5 years ago|reply
[+] [-] hakfoo|5 years ago|reply
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.
[+] [-] marcinzm|5 years ago|reply
[+] [-] XCSme|5 years ago|reply
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.
[+] [-] dstick|5 years ago|reply
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 :)
[+] [-] toyota86|5 years ago|reply
> 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
[+] [-] konschubert|5 years ago|reply
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.
[+] [-] ChrisMarshallNY|5 years ago|reply
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.
[+] [-] valuearb|5 years ago|reply
[+] [-] rapnie|5 years ago|reply
The 'move slow an make things' movement is a much-needed niche to be explored, and a place where I'd love to be.
[+] [-] mathgladiator|5 years ago|reply
"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.
[+] [-] dtjohnnyb|5 years ago|reply
[+] [-] rectang|5 years ago|reply
For a tech business, "move slow and make things" can only be a joke. But for a developer collective, it can be real.
[+] [-] systemvoltage|5 years ago|reply
[+] [-] exabrial|5 years ago|reply
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.
[+] [-] pdimitar|5 years ago|reply
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.
[+] [-] jmull|5 years ago|reply
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.
[+] [-] lupire|5 years ago|reply
[+] [-] samueladam|5 years ago|reply
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.
[+] [-] deadA1ias|5 years ago|reply
[+] [-] pcthrowaway|5 years ago|reply
[+] [-] jmjanzen|5 years ago|reply
[+] [-] ehnto|5 years ago|reply
[+] [-] bovermyer|5 years ago|reply
[+] [-] nicbou|5 years ago|reply
[+] [-] TrispusAttucks|5 years ago|reply
The slogan is pure gold.
"move slow and make things."
[+] [-] lmarcos|5 years ago|reply
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.
[+] [-] imhoguy|5 years ago|reply
https://en.m.wikipedia.org/wiki/Right_to_explanation
[+] [-] nicbou|5 years ago|reply
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.
[+] [-] pdimitar|5 years ago|reply
It's just that the current way of doing things is financially incentivized.
[+] [-] halfmatthalfcat|5 years ago|reply
[+] [-] mseepgood|5 years ago|reply