7 ms·

Ask HN: Anti-patterns from Big Tech that smaller companies should avoid?

Smaller companies often look to large companies like FAANG to design their systems, corporate processes and engineering practices. But are there practices used at these large companies that small and medium sized companies should not emulate?

NicoJuicy 5y ago
Microservices is an solution to an organisational problem. Make sure you use it when you need it. Not because others do it.
- raxxorrax 5y ago
  I think large companies often abuse it as a method for problem dissection. Reminds me of my university group that used git as a sync service.
  - NicoJuicy 5y ago
    Large organisations largely think about Conway's law when doing Microservices and that information is left behind when sharing how they did Microservices. Since the why is mostly a management reason. https://www.nagarro.com/en/blog/post/76/microservices-revisiting-conway-s-law https://www.nagarro.com/en/blog/post/76/microservices-revisi...
f0e4c2f7 5y ago
There is a snarky saying at one of the large tech companies that goes something like "I don't know how to count that low." When you're facing off against large companies as a smaller player this is one of the tricks you can use for leverage. You can serve the markets that larger companies feel safe ignoring because they are currently small. They should however be markets that you expect to grow over time. Paul Graham talks about this in some detail in his essay "do things that don't scale". http://paulgraham.com/ds.html http://paulgraham.com/ds.html
speedgoose 5y ago
Microservices should be avoided in my humble opinion. The maintenance cost is just too high for small and medium companies.
- giantg2 5y ago
  I think I agree. At least the way our company does microservices and staffing, this makes sense. We have a team if about 6 devs owning about 12 apps, many of them microservices. The overhead for technical upgrades and prod support is high. They always want us working on new stuff too. If a product owning team is around long enough, eventually you have to stop adding new apps to that team unless you retire some of the old ones.
- PaulHoule 5y ago
  Two takes I have on micro services. (1) I had a system which was mostly affordable to run except for one part that had very different needs. Breaking that into a separate system implemented differently kept the whole thing alive for another two years in a tough environment. (2) Decoupling dependencies and patterns is not a strength of microservices it is death itself. If you have JDK 6 here, JDK 7, and JDK 8 in different places because you can’t afford to update you will find you can’t afford the differences. If you do everything the same way in every microservice then the microservice architecture is not any more expensive than the macroservice architecture. If you think you get freedom by doing it any random way you are really in slavery.
zaphar 5y ago
I would say the biggest practice that smaller companies should not emulate is "rolling your own" otherwise known as "not invented here". For a large FAANG company creating your own versions of things can potentially pay off and if they don't those companies can eat the investment cost with out too much trouble. Smaller companies should focus on the business problems though instead of rolling their own database, orchestration, or programming language. At a large enough size doing any of those things may pay off but when you are smaller they are just a distraction from your core business.
- avmich 5y ago
  I'd recommend the opposite. Learning tons of 3rd party tools and relying on multitude of external dependencies is dangerous, especially when company can't afford sudden downtime or security breaches. For simple enough tasks, like many those tools on the market are solving, it's arguably better to create a tailored version in-house than to learn the approximation from the market, then spend resources associated with long-term costs - upgrades, learning, payments... Focusing on business problems is good and all, but if you're ruthlessly outsource everything else, you'll find yourself in the middle of patchy solution with little control and no end of gotchas - technical and otherwise. If you plan to use 10% of a tool and going to pay for 100%, for startups it should be a no-brainer decision.
  - closeparen 5y ago
    If you can’t afford downtime and security breaches, you can’t afford to be shipping an amateur and half baked version of something that externally is backed by a bigger and more skilled team than your entire engineering org. You can potentially simplify your approach so you don’t need anything in the category.
  - zaphar 5y ago
    There is always going to be some nuance. But there is a big difference between implementing your own database and implementing your own deployment script. Starting out small and adding tools to your toolbox is going to be a judgement call. But too much NIH and you spend all your time reimplementing Bigtable or Cockroachdb instead of building your product.
giantg2 5y ago
Developer chapter leads as managers. I believe this is a model from Netflix. It's absolute garbage at my company. I want to say it's because we have IT as a cost center, but it might run deeper than that. Who honesty thinks that making a senuor developer split their time between managing people who aren't on their team and coding for their own team is a good idea?
gravypod 5y ago
1. It is impossible to be, at the same time, a "good engineer" and "difficult to work with". FAANG can hire 30 people to work next to one toxic person so their impact can be 1/30th the pain. 2. Interviewing. FAANG can waste 30+ engineering hours on each candidate because of how much money they can burn. Don't do leetcode interviews. Find someone who you think is good, hire them, if they're not good let them go. Don't make a soul crushing interview process. 3. Open office / an office. It's a complete waste for most startups (unless you're a hardware company and can't send the hardware units to each dev). It's a sunk cost and "back in my day"-ism in FAANG.
- JasonCannon 5y ago
  >2. Interviewing. FAANG can waste 30+ engineering hours on each candidate because of how much money they can burn. Don't do leetcode interviews. Find someone who you think is good, hire them, if they're not good let them go. Don't make a soul crushing interview process. The only "algo" I have people do is a simple Fibonacci algo. Other then that, we chat about development. It's fairly easy to determine if someone knows how to develop software, and I'm just trying to find people with the right attitude that I know I can work with. Then I give them a few months, if they don't cut it, then we part ways. That's happened once.
  - JasonCannon 5y ago
    Not sure why I got downvoted for this. I assume because of the other comment saying that doing this is "cruel" which it isn't. At all. If someone lies and says they know how to develop, can talk about development in depth, but can't actually develop any software that's on them. I've had to fire people who did stupid algorithims and harder interviews after a few months just like the one time that I've done so with my current technique. In all cases, it's been because the person I interviewed lied. In the cases with stupid algo tests they studied how to leetcode, and not how to actually develop software.
- dyingkneepad 5y ago
  Hiring someone just to fire them later because you didn't bother to interview properly is extremely cruel!! Seriously, don't do that.
trimangle 5y ago
corporate process - more of a problem in mid size companies, but: installing execs / VPs from large tech companies. they replace all the managers down the chain and stir a bunch of crap up, and usually only the poor performing ICs are left at the end.
thomastjeffery 5y ago
Don't try to be a large company. Large companies suck. They obsess over processes and demand formality. The best thing about working at a startup is that it's a startup! At a startup, you can be informal. You can do work that wasn't assigned to you. You can communicate with everyone on the team directly. You can change your planned design and get right to working on those changes. People think that companies are big because of the convoluted processes they use. It's the other way around. If you have 100 people to do 95 things, then it makes sense to give every person a specific structured role. Else, why have 100 people at all? When you only have 30 people to do those 95 things, then your structure not only has to be, but can be much more organic and fluid.
bdavisx 5y ago
Don't interview like FAANG unless you're offering the same compensation - otherwise you're going to get a lot of people dropping out of your funnel because the BS isn't worth it for what you're offering.
salawat 5y ago
Off the top of my head: CI/CD is two processes, not one. You cannot put code in prod and say you regressed it unless you drop everything in an instrumented environment, and ran everything against it. Just because you hired a bunch of software engineers, you are not obviated from keeping around someone who knows what they are doing. There are two faces to Quality: 1-I will negate this suffering 2-I will replace one form of suffering with another, to buy time, and exploit the human tolerance/blindspot for churn and novelty to keep my revenue coming in. 1 is incredibly difficult, expensive, and full of work you just cannot avoid or get around. 2 is easy, modus operandi, and actually synergizes with multiple other business cycles, and is thus considered the "No one ever got fired for buying IBM" route. If you are not doing 1 you are doing 2 by default.
josephcsible 5y ago
Kubernetes isn't the be-all and end-all of how to run your applications.
- defaultprimate 5y ago
  I would venture to state that Kubernetes is not a good, cost effective solution for >90% of the applications it's used for.
- mountainriver 5y ago
  Just got to a startup, they took this point of view and now they have a terribly hacky ECS setup where they have basically rewritten most of kube’s functionality. K8s isn’t for all problems, but makes sure it isn’t for yours before you rewrite it in a much worse way.
closeparen 5y ago
In my company actually developing the product features is a low status activity. Everyone strives to be someone who influences how the features are developed - by making platforms, by writing standards, by leading meetings - but it’s understood that you’ll never be promoted or paid well if you’re the one actually coding end-user functionality. Don’t do that. Center and value the actual software construction; make sure you treat the “meta” as an unfortunately necessary cost rather than the goal.
RiverBucketShoe 5y ago
using java spring framework
- vivty 5y ago
  Could you elaborate why the java spring framework is a bad choice? I wanted to get into backend development and i thought spring is a good and battle tested framework? I also thought of using rust, elixir or go. I chose java spring because i already know java and compared to rust and elixir the support for third party libraries is much bigger.
  - devonkim 5y ago
    The Java ecosystem is culturally heavyweight and verbose with the needs of very large, bureaucratic organizations and Spring is one of the biggest examples of it (although Spring Boot has done a fair bit to modernize workflows). The struggle I can point to with a previous company was that our Java based stack made hiring extremely hard for our small company because large companies with deep pockets could hire for largely the same job at double our budgets, and for people wanting to work on sexier languages and platforms such as Rust, Go, or even Python other small companies offered that freedom. The hiring pipeline was so problematic it’s led to several years of delays rolling out features that the rest of the market has had and whatever intrinsic advantages the business had is possibly irrelevant as even the larger players have been able to do 99% of the same things. So being able to quickly move is a large advantage of being a smaller organization and anything that demonstrably hurts that advantage should be stricken from the company’s investments ASAP as long as it stays small and has no other material market advantage. It really all depends upon what makes sense for one’s situation but I was very frustrated with our hiring pipeline and the outdated stack made things much more complicated to do basic things than it should have.

NicoJuicy 5y ago

Microservices is an solution to an organisational problem. Make sure you use it when you need it. Not because others do it.

raxxorrax 5y ago
I think large companies often abuse it as a method for problem dissection. Reminds me of my university group that used git as a sync service.
- NicoJuicy 5y ago
  Large organisations largely think about Conway's law when doing Microservices and that information is left behind when sharing how they did Microservices. Since the why is mostly a management reason. https://www.nagarro.com/en/blog/post/76/microservices-revisiting-conway-s-law https://www.nagarro.com/en/blog/post/76/microservices-revisi...

f0e4c2f7 5y ago

There is a snarky saying at one of the large tech companies that goes something like "I don't know how to count that low." When you're facing off against large companies as a smaller player this is one of the tricks you can use for leverage. You can serve the markets that larger companies feel safe ignoring because they are currently small. They should however be markets that you expect to grow over time. Paul Graham talks about this in some detail in his essay "do things that don't scale". http://paulgraham.com/ds.html http://paulgraham.com/ds.html

speedgoose 5y ago

Microservices should be avoided in my humble opinion. The maintenance cost is just too high for small and medium companies.

giantg2 5y ago
I think I agree. At least the way our company does microservices and staffing, this makes sense. We have a team if about 6 devs owning about 12 apps, many of them microservices. The overhead for technical upgrades and prod support is high. They always want us working on new stuff too. If a product owning team is around long enough, eventually you have to stop adding new apps to that team unless you retire some of the old ones.
PaulHoule 5y ago
Two takes I have on micro services. (1) I had a system which was mostly affordable to run except for one part that had very different needs. Breaking that into a separate system implemented differently kept the whole thing alive for another two years in a tough environment. (2) Decoupling dependencies and patterns is not a strength of microservices it is death itself. If you have JDK 6 here, JDK 7, and JDK 8 in different places because you can’t afford to update you will find you can’t afford the differences. If you do everything the same way in every microservice then the microservice architecture is not any more expensive than the macroservice architecture. If you think you get freedom by doing it any random way you are really in slavery.

zaphar 5y ago

I would say the biggest practice that smaller companies should not emulate is "rolling your own" otherwise known as "not invented here". For a large FAANG company creating your own versions of things can potentially pay off and if they don't those companies can eat the investment cost with out too much trouble. Smaller companies should focus on the business problems though instead of rolling their own database, orchestration, or programming language. At a large enough size doing any of those things may pay off but when you are smaller they are just a distraction from your core business.

avmich 5y ago
I'd recommend the opposite. Learning tons of 3rd party tools and relying on multitude of external dependencies is dangerous, especially when company can't afford sudden downtime or security breaches. For simple enough tasks, like many those tools on the market are solving, it's arguably better to create a tailored version in-house than to learn the approximation from the market, then spend resources associated with long-term costs - upgrades, learning, payments... Focusing on business problems is good and all, but if you're ruthlessly outsource everything else, you'll find yourself in the middle of patchy solution with little control and no end of gotchas - technical and otherwise. If you plan to use 10% of a tool and going to pay for 100%, for startups it should be a no-brainer decision.
- closeparen 5y ago
  If you can’t afford downtime and security breaches, you can’t afford to be shipping an amateur and half baked version of something that externally is backed by a bigger and more skilled team than your entire engineering org. You can potentially simplify your approach so you don’t need anything in the category.
- zaphar 5y ago
  There is always going to be some nuance. But there is a big difference between implementing your own database and implementing your own deployment script. Starting out small and adding tools to your toolbox is going to be a judgement call. But too much NIH and you spend all your time reimplementing Bigtable or Cockroachdb instead of building your product.

giantg2 5y ago

Developer chapter leads as managers. I believe this is a model from Netflix. It's absolute garbage at my company. I want to say it's because we have IT as a cost center, but it might run deeper than that. Who honesty thinks that making a senuor developer split their time between managing people who aren't on their team and coding for their own team is a good idea?

gravypod 5y ago

1. It is impossible to be, at the same time, a "good engineer" and "difficult to work with". FAANG can hire 30 people to work next to one toxic person so their impact can be 1/30th the pain. 2. Interviewing. FAANG can waste 30+ engineering hours on each candidate because of how much money they can burn. Don't do leetcode interviews. Find someone who you think is good, hire them, if they're not good let them go. Don't make a soul crushing interview process. 3. Open office / an office. It's a complete waste for most startups (unless you're a hardware company and can't send the hardware units to each dev). It's a sunk cost and "back in my day"-ism in FAANG.

JasonCannon 5y ago
>2. Interviewing. FAANG can waste 30+ engineering hours on each candidate because of how much money they can burn. Don't do leetcode interviews. Find someone who you think is good, hire them, if they're not good let them go. Don't make a soul crushing interview process. The only "algo" I have people do is a simple Fibonacci algo. Other then that, we chat about development. It's fairly easy to determine if someone knows how to develop software, and I'm just trying to find people with the right attitude that I know I can work with. Then I give them a few months, if they don't cut it, then we part ways. That's happened once.
- JasonCannon 5y ago
  Not sure why I got downvoted for this. I assume because of the other comment saying that doing this is "cruel" which it isn't. At all. If someone lies and says they know how to develop, can talk about development in depth, but can't actually develop any software that's on them. I've had to fire people who did stupid algorithims and harder interviews after a few months just like the one time that I've done so with my current technique. In all cases, it's been because the person I interviewed lied. In the cases with stupid algo tests they studied how to leetcode, and not how to actually develop software.
dyingkneepad 5y ago
Hiring someone just to fire them later because you didn't bother to interview properly is extremely cruel!! Seriously, don't do that.

trimangle 5y ago

corporate process - more of a problem in mid size companies, but: installing execs / VPs from large tech companies. they replace all the managers down the chain and stir a bunch of crap up, and usually only the poor performing ICs are left at the end.

thomastjeffery 5y ago

Don't try to be a large company. Large companies suck. They obsess over processes and demand formality. The best thing about working at a startup is that it's a startup! At a startup, you can be informal. You can do work that wasn't assigned to you. You can communicate with everyone on the team directly. You can change your planned design and get right to working on those changes. People think that companies are big because of the convoluted processes they use. It's the other way around. If you have 100 people to do 95 things, then it makes sense to give every person a specific structured role. Else, why have 100 people at all? When you only have 30 people to do those 95 things, then your structure not only has to be, but can be much more organic and fluid.

bdavisx 5y ago

Don't interview like FAANG unless you're offering the same compensation - otherwise you're going to get a lot of people dropping out of your funnel because the BS isn't worth it for what you're offering.

salawat 5y ago

Off the top of my head: CI/CD is two processes, not one. You cannot put code in prod and say you regressed it unless you drop everything in an instrumented environment, and ran everything against it. Just because you hired a bunch of software engineers, you are not obviated from keeping around someone who knows what they are doing. There are two faces to Quality: 1-I will negate this suffering 2-I will replace one form of suffering with another, to buy time, and exploit the human tolerance/blindspot for churn and novelty to keep my revenue coming in. 1 is incredibly difficult, expensive, and full of work you just cannot avoid or get around. 2 is easy, modus operandi, and actually synergizes with multiple other business cycles, and is thus considered the "No one ever got fired for buying IBM" route. If you are not doing 1 you are doing 2 by default.

josephcsible 5y ago

Kubernetes isn't the be-all and end-all of how to run your applications.

defaultprimate 5y ago
I would venture to state that Kubernetes is not a good, cost effective solution for >90% of the applications it's used for.
mountainriver 5y ago
Just got to a startup, they took this point of view and now they have a terribly hacky ECS setup where they have basically rewritten most of kube’s functionality. K8s isn’t for all problems, but makes sure it isn’t for yours before you rewrite it in a much worse way.

closeparen 5y ago

In my company actually developing the product features is a low status activity. Everyone strives to be someone who influences how the features are developed - by making platforms, by writing standards, by leading meetings - but it’s understood that you’ll never be promoted or paid well if you’re the one actually coding end-user functionality. Don’t do that. Center and value the actual software construction; make sure you treat the “meta” as an unfortunately necessary cost rather than the goal.

RiverBucketShoe 5y ago

using java spring framework

vivty 5y ago
Could you elaborate why the java spring framework is a bad choice? I wanted to get into backend development and i thought spring is a good and battle tested framework? I also thought of using rust, elixir or go. I chose java spring because i already know java and compared to rust and elixir the support for third party libraries is much bigger.
- devonkim 5y ago
  The Java ecosystem is culturally heavyweight and verbose with the needs of very large, bureaucratic organizations and Spring is one of the biggest examples of it (although Spring Boot has done a fair bit to modernize workflows). The struggle I can point to with a previous company was that our Java based stack made hiring extremely hard for our small company because large companies with deep pockets could hire for largely the same job at double our budgets, and for people wanting to work on sexier languages and platforms such as Rust, Go, or even Python other small companies offered that freedom. The hiring pipeline was so problematic it’s led to several years of delays rolling out features that the rest of the market has had and whatever intrinsic advantages the business had is possibly irrelevant as even the larger players have been able to do 99% of the same things. So being able to quickly move is a large advantage of being a smaller organization and anything that demonstrably hurts that advantage should be stricken from the company’s investments ASAP as long as it stays small and has no other material market advantage. It really all depends upon what makes sense for one’s situation but I was very frustrated with our hiring pipeline and the outdated stack made things much more complicated to do basic things than it should have.