7 ms·

A lot of folks will claim all of this is just survivorship bias, but I believe there are lessons to learn. For example most of the extremely successful software

by hbrn 4y ago

A lot of folks will claim all of this is just survivorship bias, but I believe there are lessons to learn. For example most of the extremely successful software products produced by small teams have a heavy focus on UX. Arguably, it is nearly impossible to achieve in a big team, because UX is a bottleneck that is hard to scale. I also find it really sad that a lot of the small teams who are on the road to success get distracted by applying "best practices" that were built for big teams (e.g. Google uses kubernetes, we should too).

eyelidlessness 4y ago
An interesting case here is Craigslist. I won’t say their UX is poor per se, but it’s very much a matter of taste that not everyone shares. Notably, the Venn diagram of their user base and the people who vocally laud their UX is likely an enormous circle with a competitively tiny one hiding inside it (respectively). I think it’s interesting because while I personally don’t like the Craigslist UX, I have no objection to using it anyway (even if might I try other solutions first). They provide enough other value to me, and the UX is good enough, that I still have an overall positive impression of the service. I also find it interesting because the debatability of their UX is really very surface level. There are all kinds of things I wish were different, but that’s mostly because it was perfectly fine in 200* and hasn’t much changed with the times beyond a few utilitarian niceties. I’m sure this is way overly specific to CL as a reply, but your comment about UX focus resonates with me, and I’ve long found Craigslist’s lasting success fascinating in this light.
- jdougan 4y ago
  On the other hand, stability has value too. I can go onto CL and immediately know how I'm going to drive it, because it has been so stable. This can save a surprising amount of time.
  - eyelidlessness 4y ago
    Yep this is what I meant to acknowledge. Whatever other UX complaints I might have, it’s consistent and predictable and that’s a lot of why I don’t have a problem overlooking my gripes.
- twelvechairs 4y ago
  Craiglist has great usability, its just aesthetically bland. Usability is generally the most important part of 'UX' though the 'UX industry' skews towards the attractiveness side (particularly latest aesthetic trends) as their input is easier to see/quantify there. The other important side is marketing/branding and in some ways craigslist has built that brand around its 'basic' interface.
  - eyelidlessness 4y ago
    None of my UX complaints are about attractiveness, there are several usability difficulties for me using CL. I hope it stays brutalist and ugly and plain forever. Most of my UX complaints are about ambiguous navigation and state, which are consistent with UX from a time when web programming had those problems almost universally.
    - TeMPOraL 4y ago
      Thanks for elaborating - but to reinforce GP's point, usability and ergonomics is a huge problem on the modern web. Personally, I'm heavily positively biased to simple and old-school UIs because, despite all the things they got wrong (like the ones you mention), they hail from an era where people cared about ergonomics, or at least weren't purposefully trying to make it bad. Simple, "brutalist" design is thus a signal for me that the site is much more likely to not be actively user-hostile. Modern UI/UX zeitgeist is driven in large part by the web and mobile, which are driven by the "attention economy". The defining aspect of attention economy is that it makes money on friction. The longer it takes you to accomplish your goals, the more opportunities there is to display you ads, or upsell you something, or tire you out and make you more susceptible to be funneled to where the vendor wants you to be. The major design guidelines and UI frameworks are written and provided by advertising companies, and are focused on controlling the interaction, not empowering users. In this environment, ergonomics and good experience - meaning a tool that helps users achieve what they want as fast as possible, and gets out of the way otherwise - is actively discouraged.
  - danjac 4y ago
    As with developers doing resume-driven development, designers need to build a strong portfolio to land their next gig. So aesthetics comes into building their own distinctive "brand" (as opposed to the brand of the client/company they are currently working for). That's not to say they won't justify their design in terms of what the client needs, it just pushes them away from using "boring" aesthetics - for example, pushing for a trendy-looking design for a backend admin dashboard that would have been just as usable (and cheaper) to build with a bog-standard Bootstrap theme. This isn't to blame designers, that's just the economic reality of the business.
kixxauth 4y ago
> I also find it really sad that a lot of the small teams who are on the road to success get distracted by applying "best practices" that were built for big teams (e.g. Google uses kubernetes, we should too). Totally. It takes some experience and maturity to be confident enough to resist the big business “best” practices. That, or a very intuitive entrepreneur
- Aperocky 4y ago
  Simple is better than complex. Frame this quote on the wall beside the monitor, things will magically (simply?) improve.
  - andreareina 4y ago
    The good kind of simplicity is hard. I’ve seen (and built) a bunch of things that were too simple and consequently underpowered for the task at hand[1]. Then there’s the issue of, ok this thing definitely needs to be done; do we do it in this module or in that one? This is all separate from the tendency to conflate simple with what’s easy [2]. [1] <rant>poetry doesn’t understand that when I ` poetry add foo` I don’t want the latest version, I want the latest version that is compatible with the rest of my declared dependencies, especially my declared Python version</rant> [2] https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/
    - TeMPOraL 4y ago
      > <rant>poetry doesn’t understand that when I ` poetry add foo` I don’t want the latest version, I want the latest version that is compatible with the rest of my declared dependencies, especially my declared Python version</rant> IIRC, the command was $ poetry add foo most recent \ which fits this crowd most decent
  - arkh 4y ago
    I prefer "simple is not easy".
  - noirscape 4y ago
Sparkyte 4y ago
I don't believe that one bit. They have a scoped heavy perspective on what they are doing so they don't skew into feature creep. It has nothing to do with big teams and little teams. Either model can work as long as you break projects down and prevent feature creep. The more features a service has to support the larger the team has to be and thus enters feature creep. And there is Product teams who think they are smarter than everyone claiming more feature ideas while increasing their department size and this only adds to feature creep because literally it is just echo chamber of development hell.
- danjac 4y ago
  The thing is that "feature creep" is a symptom rather than cause. "Feature creep" in a small company is a sign of flailing around trying to capture a market. Sometimes a whole new feature is developed under pressure from Sales to land a big whale client, or a desperate CEO who thinks runaway success is just that one key feature away. In a big company feature creep may be the result of a corporate culture that doles out promotions and bonuses for building shiny new things rather than the boring work of maintaining old things. Google is a good example of this, only with entire new services rather than features. Either way feature creep is symptomatic of deeper problems with a company, regardless of size.
  - Sparkyte 4y ago
    I completely agree. You can certainly have it at all sizes and the runaway of feature creep usually ends up in over hiring.
- Nathanael_M 4y ago
  I really appreciate this comment. You've very clearly presented a problem that I hadn't considered and now that you've presented it, I can immediately see it in my work life. The business I'm with is suffering from "service" creep. "We can and will do anything." It's really damaging the quality of our services and putting a lot of pressure on us to expand in a direction that's not our biggest area of opportunity. You've given my something to think about.
allenleee 4y ago
> ...a lot of the small teams who are on the road to success get distracted by applying "best practices" that were built for big teams OKR
- ramijames 4y ago
  OKRs are just about the worst way to gauge success at a small scale.
  - YANNIC-G 4y ago
    Can you elaborate on that? I'm not that familiar with OKR.
- jbergens 4y ago
  Oh no, we are starting with that now.
roenxi 4y ago
Worth explaining a little more why survivorship bias doesn't apply here - the point is that small teams are capable of achieving billions of dollars worth of value add. This is closer to a claim of existence. Obviously most small teams don't generate that much value. There are a lot of tiny podcasters out there. Nobody is going to mistakenly think that all small teams are Joe Rogan. But it is nevertheless possible for a small team to be absurdly productive given the right conditions - success isn't about team size, it is about the opportunity and available skillset. FWIW, politics is very similar. One person can't achieve very much, but a small group can wield devastating levels of power.
- niels_bom 4y ago
  Can you elaborate on why you think survivorship bias doesn’t apply here? If you fall off a ship in the middle of the ocean you might survive and those survivors may have had strategies but we just don’t know if the people that died did not have the same strategies. Same goes for this list I’d think.
  - deleted 4y ago
    [deleted]
  - eloisant 4y ago
    We hear about hugely successful small teams because they made it and became famous. We don't hear about all the small teams who either fail, or keep a small (yet self-sustaining) revenue without ever becoming hugely successful. So listing examples proves that it's possible for a small team to achieve a huge success. It doesn't prove that a small team is more likely to achieve success than a bigger one.
  - roenxi 4y ago
    > If you fall off a ship in the middle of the ocean you might survive and those survivors may have had strategies... They quite likely do have strategies. People with successful strategies are vastly over-represented in pools of survivors. Hence the bias. The pool of survivors is skewed towards successful strategies, and does not represent the population of people who attempted the thing. The bias would be noting that survivors used a range of clever strategies and then making tools available to support those strategies in an attempt to help people at sea. Survivorship bias is about noting that of course the survivors did things that worked, and to get better outcomes we need to focus on people using strategies that aren't represented when sampling from the pool of survivors.
danjac 4y ago
My favourite tin-foil hat conspiracy theory is that Kubernetes, microservices etc are promoted by big tech to lure potentially disruptive small teams into adopting momentum-killing rabbit-hole solutions because they are "best practice"... This also holds for project management practices such as Scrum.
- gloosx 4y ago
  Actually used k8s for the first time ever to set-up a new product from scratch. I would call it essentially an Autobahn whereas everything else was a dirt road. Our team is just 3 people, and it took me just 1 week and 1 youtube video to setup a 100% availability load-balanced production env cluster with 5 node.js microservices, and it is working like a charm, rollout deployment takes 30-60 seconds and i can monitor it all at glance without leaving my terminal. UPD: I was into your theory too before:)
  - concordDance 4y ago
    What was the video?
    - gloosx 4y ago
      Happy to share! This guy just made it a breeze for me. https://www.youtube.com/watch?v=heQbbrSu8LM https://www.youtube.com/watch?v=heQbbrSu8LM
  - lmarcos 4y ago
    This is the equivalent of "My cousin can build me a website in a weekend. Why are you charging me so much Mr. software engineer?"
    - deleted 4y ago
      [deleted]
  - TeMPOraL 4y ago
    At this point it could be simply that enough bodies were thrown at k8s and related tooling that, though oceans of sweat, blood and tears, rough edges were filed down or at least marked as dangerous, and enough iterations of guides and tutorials were made that, finally, you can set up a production cluster with one week and one YouTube video and no human sacrifice.
TeMPOraL 4y ago
> I also find it really sad that a lot of the small teams who are on the road to success get distracted by applying "best practices" that were built for big teams (e.g. Google uses kubernetes, we should too). Principal-agent problem, i.e. conflicting goals. Sometimes it's the team vs. company, sometimes it's the team or a person against themselves. There are choices that are most beneficial for the current project, and there are choices that are most beneficial for one's career after the current project, and/or choices that are most interesting to the person. So e.g. Kubernetes may be a total overkill for most things anyone does, but if I get around to doing some side project where Kubernetes would be a fit, even if rather poor, you can bet I'll at least try to use it, because it's highly likely I'll encounter it later at my current or future job. Now, this is just my side project, but then, many (most?) widely-used FLOSS software started as someone's side project. And the same reasoning happens in companies big and small, as failing to keep your skills fresh is a recipe for trouble sooner or later, and the industry-standard approach to software developers' growth is "figure it out on your own, we're paying you for labor, not for your professional growth".
- danjac 4y ago
  a.k.a. resume-driven development
rgavuliak 4y ago
I think UX is a heavy focus because most of these are B2C where UX matters more. Than again B2B solutions are probably more difficult to build with a smaller team.
baxtr 4y ago
Heavy focus on UX like Craigslist you mean? (they're also on that list)

by hbrn 4y ago

eyelidlessness 4y ago

An interesting case here is Craigslist. I won’t say their UX is poor per se, but it’s very much a matter of taste that not everyone shares. Notably, the Venn diagram of their user base and the people who vocally laud their UX is likely an enormous circle with a competitively tiny one hiding inside it (respectively). I think it’s interesting because while I personally don’t like the Craigslist UX, I have no objection to using it anyway (even if might I try other solutions first). They provide enough other value to me, and the UX is good enough, that I still have an overall positive impression of the service. I also find it interesting because the debatability of their UX is really very surface level. There are all kinds of things I wish were different, but that’s mostly because it was perfectly fine in 200* and hasn’t much changed with the times beyond a few utilitarian niceties. I’m sure this is way overly specific to CL as a reply, but your comment about UX focus resonates with me, and I’ve long found Craigslist’s lasting success fascinating in this light.

jdougan 4y ago
On the other hand, stability has value too. I can go onto CL and immediately know how I'm going to drive it, because it has been so stable. This can save a surprising amount of time.
- eyelidlessness 4y ago
  Yep this is what I meant to acknowledge. Whatever other UX complaints I might have, it’s consistent and predictable and that’s a lot of why I don’t have a problem overlooking my gripes.
twelvechairs 4y ago
Craiglist has great usability, its just aesthetically bland. Usability is generally the most important part of 'UX' though the 'UX industry' skews towards the attractiveness side (particularly latest aesthetic trends) as their input is easier to see/quantify there. The other important side is marketing/branding and in some ways craigslist has built that brand around its 'basic' interface.
- eyelidlessness 4y ago
  None of my UX complaints are about attractiveness, there are several usability difficulties for me using CL. I hope it stays brutalist and ugly and plain forever. Most of my UX complaints are about ambiguous navigation and state, which are consistent with UX from a time when web programming had those problems almost universally.
  - TeMPOraL 4y ago
    Thanks for elaborating - but to reinforce GP's point, usability and ergonomics is a huge problem on the modern web. Personally, I'm heavily positively biased to simple and old-school UIs because, despite all the things they got wrong (like the ones you mention), they hail from an era where people cared about ergonomics, or at least weren't purposefully trying to make it bad. Simple, "brutalist" design is thus a signal for me that the site is much more likely to not be actively user-hostile. Modern UI/UX zeitgeist is driven in large part by the web and mobile, which are driven by the "attention economy". The defining aspect of attention economy is that it makes money on friction. The longer it takes you to accomplish your goals, the more opportunities there is to display you ads, or upsell you something, or tire you out and make you more susceptible to be funneled to where the vendor wants you to be. The major design guidelines and UI frameworks are written and provided by advertising companies, and are focused on controlling the interaction, not empowering users. In this environment, ergonomics and good experience - meaning a tool that helps users achieve what they want as fast as possible, and gets out of the way otherwise - is actively discouraged.
- danjac 4y ago
  As with developers doing resume-driven development, designers need to build a strong portfolio to land their next gig. So aesthetics comes into building their own distinctive "brand" (as opposed to the brand of the client/company they are currently working for). That's not to say they won't justify their design in terms of what the client needs, it just pushes them away from using "boring" aesthetics - for example, pushing for a trendy-looking design for a backend admin dashboard that would have been just as usable (and cheaper) to build with a bog-standard Bootstrap theme. This isn't to blame designers, that's just the economic reality of the business.

kixxauth 4y ago

> I also find it really sad that a lot of the small teams who are on the road to success get distracted by applying "best practices" that were built for big teams (e.g. Google uses kubernetes, we should too). Totally. It takes some experience and maturity to be confident enough to resist the big business “best” practices. That, or a very intuitive entrepreneur

Aperocky 4y ago
Simple is better than complex. Frame this quote on the wall beside the monitor, things will magically (simply?) improve.
- andreareina 4y ago
  The good kind of simplicity is hard. I’ve seen (and built) a bunch of things that were too simple and consequently underpowered for the task at hand[1]. Then there’s the issue of, ok this thing definitely needs to be done; do we do it in this module or in that one? This is all separate from the tendency to conflate simple with what’s easy [2]. [1] <rant>poetry doesn’t understand that when I ` poetry add foo` I don’t want the latest version, I want the latest version that is compatible with the rest of my declared dependencies, especially my declared Python version</rant> [2] https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/
  - TeMPOraL 4y ago
    > <rant>poetry doesn’t understand that when I ` poetry add foo` I don’t want the latest version, I want the latest version that is compatible with the rest of my declared dependencies, especially my declared Python version</rant> IIRC, the command was $ poetry add foo most recent \ which fits this crowd most decent
- arkh 4y ago
  I prefer "simple is not easy".
- noirscape 4y ago

Sparkyte 4y ago

I don't believe that one bit. They have a scoped heavy perspective on what they are doing so they don't skew into feature creep. It has nothing to do with big teams and little teams. Either model can work as long as you break projects down and prevent feature creep. The more features a service has to support the larger the team has to be and thus enters feature creep. And there is Product teams who think they are smarter than everyone claiming more feature ideas while increasing their department size and this only adds to feature creep because literally it is just echo chamber of development hell.

danjac 4y ago
The thing is that "feature creep" is a symptom rather than cause. "Feature creep" in a small company is a sign of flailing around trying to capture a market. Sometimes a whole new feature is developed under pressure from Sales to land a big whale client, or a desperate CEO who thinks runaway success is just that one key feature away. In a big company feature creep may be the result of a corporate culture that doles out promotions and bonuses for building shiny new things rather than the boring work of maintaining old things. Google is a good example of this, only with entire new services rather than features. Either way feature creep is symptomatic of deeper problems with a company, regardless of size.
- Sparkyte 4y ago
  I completely agree. You can certainly have it at all sizes and the runaway of feature creep usually ends up in over hiring.
Nathanael_M 4y ago
I really appreciate this comment. You've very clearly presented a problem that I hadn't considered and now that you've presented it, I can immediately see it in my work life. The business I'm with is suffering from "service" creep. "We can and will do anything." It's really damaging the quality of our services and putting a lot of pressure on us to expand in a direction that's not our biggest area of opportunity. You've given my something to think about.

allenleee 4y ago

> ...a lot of the small teams who are on the road to success get distracted by applying "best practices" that were built for big teams OKR

ramijames 4y ago
OKRs are just about the worst way to gauge success at a small scale.
- YANNIC-G 4y ago
  Can you elaborate on that? I'm not that familiar with OKR.
jbergens 4y ago
Oh no, we are starting with that now.

roenxi 4y ago

Worth explaining a little more why survivorship bias doesn't apply here - the point is that small teams are capable of achieving billions of dollars worth of value add. This is closer to a claim of existence. Obviously most small teams don't generate that much value. There are a lot of tiny podcasters out there. Nobody is going to mistakenly think that all small teams are Joe Rogan. But it is nevertheless possible for a small team to be absurdly productive given the right conditions - success isn't about team size, it is about the opportunity and available skillset. FWIW, politics is very similar. One person can't achieve very much, but a small group can wield devastating levels of power.

niels_bom 4y ago
Can you elaborate on why you think survivorship bias doesn’t apply here? If you fall off a ship in the middle of the ocean you might survive and those survivors may have had strategies but we just don’t know if the people that died did not have the same strategies. Same goes for this list I’d think.
- deleted 4y ago
  [deleted]
- eloisant 4y ago
  We hear about hugely successful small teams because they made it and became famous. We don't hear about all the small teams who either fail, or keep a small (yet self-sustaining) revenue without ever becoming hugely successful. So listing examples proves that it's possible for a small team to achieve a huge success. It doesn't prove that a small team is more likely to achieve success than a bigger one.
- roenxi 4y ago
  > If you fall off a ship in the middle of the ocean you might survive and those survivors may have had strategies... They quite likely do have strategies. People with successful strategies are vastly over-represented in pools of survivors. Hence the bias. The pool of survivors is skewed towards successful strategies, and does not represent the population of people who attempted the thing. The bias would be noting that survivors used a range of clever strategies and then making tools available to support those strategies in an attempt to help people at sea. Survivorship bias is about noting that of course the survivors did things that worked, and to get better outcomes we need to focus on people using strategies that aren't represented when sampling from the pool of survivors.

danjac 4y ago

My favourite tin-foil hat conspiracy theory is that Kubernetes, microservices etc are promoted by big tech to lure potentially disruptive small teams into adopting momentum-killing rabbit-hole solutions because they are "best practice"... This also holds for project management practices such as Scrum.

gloosx 4y ago
Actually used k8s for the first time ever to set-up a new product from scratch. I would call it essentially an Autobahn whereas everything else was a dirt road. Our team is just 3 people, and it took me just 1 week and 1 youtube video to setup a 100% availability load-balanced production env cluster with 5 node.js microservices, and it is working like a charm, rollout deployment takes 30-60 seconds and i can monitor it all at glance without leaving my terminal. UPD: I was into your theory too before:)
- concordDance 4y ago
  What was the video?
  - gloosx 4y ago
    Happy to share! This guy just made it a breeze for me. https://www.youtube.com/watch?v=heQbbrSu8LM https://www.youtube.com/watch?v=heQbbrSu8LM
- lmarcos 4y ago
  This is the equivalent of "My cousin can build me a website in a weekend. Why are you charging me so much Mr. software engineer?"
  - deleted 4y ago
    [deleted]
- TeMPOraL 4y ago
  At this point it could be simply that enough bodies were thrown at k8s and related tooling that, though oceans of sweat, blood and tears, rough edges were filed down or at least marked as dangerous, and enough iterations of guides and tutorials were made that, finally, you can set up a production cluster with one week and one YouTube video and no human sacrifice.

TeMPOraL 4y ago

> I also find it really sad that a lot of the small teams who are on the road to success get distracted by applying "best practices" that were built for big teams (e.g. Google uses kubernetes, we should too). Principal-agent problem, i.e. conflicting goals. Sometimes it's the team vs. company, sometimes it's the team or a person against themselves. There are choices that are most beneficial for the current project, and there are choices that are most beneficial for one's career after the current project, and/or choices that are most interesting to the person. So e.g. Kubernetes may be a total overkill for most things anyone does, but if I get around to doing some side project where Kubernetes would be a fit, even if rather poor, you can bet I'll at least try to use it, because it's highly likely I'll encounter it later at my current or future job. Now, this is just my side project, but then, many (most?) widely-used FLOSS software started as someone's side project. And the same reasoning happens in companies big and small, as failing to keep your skills fresh is a recipe for trouble sooner or later, and the industry-standard approach to software developers' growth is "figure it out on your own, we're paying you for labor, not for your professional growth".

danjac 4y ago
a.k.a. resume-driven development

rgavuliak 4y ago

I think UX is a heavy focus because most of these are B2C where UX matters more. Than again B2B solutions are probably more difficult to build with a smaller team.

baxtr 4y ago

Heavy focus on UX like Craigslist you mean? (they're also on that list)