14 ms·

Your tech stack is not the product

256 points by brendannee 4y ago

japanman425 4y ago
[flagged]
dmitriid 4y ago
Most of the stuff we used is based on some very boring tech. It may get upgraded to something fancy when the product/service scales to a significant number of users, but Spring+Postgres (or RoR, or Django, or PHP...) will get you there with no problems. Facebook was PHP, Instagram was Django etc. They became what they became while using incredibly boring "old-school" tech. The product is paramount, not the tech.
- ummonk 4y ago
  I mean, Facebook ended up forking PHP and writing their own type system and execution environment to make it work after they had scaled up...
  - dmitriid 4y ago
    Keyword: after they scaled up. First they became Facebook :)
cudgy 4y ago
This is why myopic technical founders need a balanced partner to help recognize the blending of company mission and company implementation. However, it is natural for a myopic technical person to want to leverage their existing skillset, as this knowledge represents to them the key value that they bring to the organization. Unfortunately, blind loyalty to technical stacks is not likely to be an advantage, long-term. The ability to balance the need to leverage existing skills and taking advantage of new skills is critical.
PaybackTony 4y ago
This is something I preach often, even at FAANG. Often engineers feel comfortable and in-the-zone when solving for a process. One saying I often delivery is: Engineers often think their job is to build things. That's not the whole story, they build things for _people_. Nobody cares what your code looks like. Nobody cares what your architecture looks like. As engineers we should worry about creating forgettable experiences (at least in enterprise). They care that it does the job well, with low load times and an easy to use UX. That's it. If you did your job right they'll forget that software helped them do their job or complete their task faster / better because the experience was so seamless they spent the entire time focused on their own goal, and not how to navigate your software to get there. How you get there is irrelevant. Now it's your job as an experienced and intelligent engineer to make quick, thoughtful decisions on how to get your product to where it needs to be so that your _customers_ can create more impact on their own business / lives faster.
- deleted 4y ago
  [deleted]
- quanticle 4y ago
  Nobody cares what your code looks like. Nobody cares what your architecture looks like. … until it breaks. Nobody cared how the FAA NOTAM database was implemented either, until it went down. Part of being a professional engineer is thinking about these things, so your users won't have to.
  - AnIdiotOnTheNet 4y ago
    Forgive me if I'm wrong about this, but it would seem to me that the FAA NOTAM system had orders of magnitude more uptime than literally any product produced by so called "professional" "engineers" at big software companies.
    - alfalfasprout 4y ago
      I think the point still stands but in a different way. The architecture was designed to be quite reliable.
deleted 4y ago
[deleted]
habitue 4y ago
> customers are not paying for, nor give a shit about, these things. Yes, but they do give a shit if: - your product is slow, so they assume it's crap and leave your site - your product breaks, no one notices or fixes it - your product is bad, because your wrote it in a safe boring technology like cobol and therefore couldn't access the best developers. (exaggeration, but variations on this are true) My point isn't that you must use the newest shiniest tech and infra to do everything, my point is that when people write blog posts like this, they want to make it seem like there's a clear line between what's "cool shiny tech" and what's "hard nosed business focused shipping". In reality, it's a lot fuzzier and these things feed back into each other. For example, you shipped bad code early on to get velocity, but it turned out to be foundational and hard to replace, so your best developers leave as your codebase becomes a ball of mud that it's become clear will never be fixed. So now your worst developers are working on a ball of mud and making it worse... etc etc. As always, the answer is that this stuff is hard, and you can't make a technology decision by just considering things a user wants to buy and saying everything else is navel gazing and messing around.
- iLoveOncall 4y ago
  > - your product is slow, so they assume it's crap and leave your site I don't think there any tech stack that will have any significant (or even just measurable) impact the speed of the product, for 99% of the startups. > - your product breaks, no one notices or fixes it This has nothing to do with the tech stack. You can setup monitoring, alarms and metrics for any tech stack. > - your product is bad, because your wrote it in a boring technology like cobol and therefore couldn't access the best developers. 99% of startups won't be able to afford the best developers anyway. 99% of startups don't need the best developers. Average developers can make great products. --- You are taking "your tech stack does not matter" and twist it into "You will have problems if you have the worst tech stack and the worst developers!". Cool, but that's not what the article is about.
  - habitue 4y ago
    > your tech stack does not matter > You will have problems if you have the worst tech stack Cool, so we've established that I'm saying the tech stack matters. All of the problems above have to do with the tech stack. Yes performance is part of your tech stack. Yes, how easily you can monitor it and is part of your tech stack. > 99% of startups won't be able to afford the best developers anyway. 99% of startups don't need the best developers. Average developers can make great products. Here again, the tech stack matters. If you have known mediocre developers, you should pick a language like Java or Go because otherwise it's going to be a mess. If you have good developers, you should trust them to pick the technologies.
bcrosby95 4y ago
> Why is Joe’s closet computer a bad choice? Because it’s a single point of failure and we won’t be able to ship fast if it breaks, which it will. It's kinda a shame they reduced it to this. A single machine in a colo center is going to be far more reliable than single availability zone in AWS, which is all many people resort to. And maybe we've just gotten lucky, but in general our very simple 20 machine colo center setup has been more reliable than our single region AWS setup. But yeah, if you literally put Joe's computer in a closet it isn't gonna be too reliable for all sorts of reasons completely unrelated to the reliability of modern computer hardware.
- andrewmutz 4y ago
  I think he literally means Joe's computer closet. Colo is fine if you can set it up extremely quickly and it takes minimal ongoing support time. Depending on what you mean by Colo, that may or may not be possible.
- themitigating 4y ago
  "It's kinda a shame they reduced it to this. A single machine in a colo center is going to be far more reliable than single availability zone" I think that depends on the colo honestly. What is so unreliable about a single EC2 instance in a zone?
  - arcturus17 4y ago
    Yea I’m left scratching my head too. Is there really a difference in reliability between an EC2 instance and colocated hardware?
    - mrkurt 4y ago
      Yes. In my experience, it's substantial. 200 servers in colo == maybe 1 failure every 6 months. 200 EC2 instances, one per month. These are different things, though. If you're using AWS, you would build to account for this.
      - 4y ago
pickledish 4y ago
I have to say I agree very much with his point, though not really the way he communicates it: > Let’s riff. I’ve had my “macho engineer” days, I’ve built that stuff. Take me deep, I’m ready. or > No; customers are not paying for, nor give a shit about, these things. Sorry. Just feels to me a bit condescending for no reason
- mik3y 4y ago
  (author here) Fair feedback, thanks! I wrote that with myself as the listener in mind -- I often need the reminder that is the post's title -- but I can see how the delivery would sound abrasive to another reader. Gave it a light edit.
0xdeadbeefbabe 4y ago
> A mindset of technology being the means, not the end, is uncomfortable. Really? That's pretty funny. How could anyone miss this lesson who has ever used a computer to do things.
- cirrus3 4y ago
  It is less funny once you've been exposed to these people frequently. I assure you they are out there, and yes they have used computers to do thing in the past, yet they behave this way still. This is kind of the point of the article.
Barrin92 4y ago
Very good post. A few years ago there was an interesting post linked here on HN about Stackoverflow's tech stack and I was surprised how simple it was. Basically a bunch of servers cache, load balancer, dotnet, sql. And in reality for most projects that is honestly just about what you need.
neilv 4y ago
> If we pick exotic technology, it’ll be harder to hire (and we won’t ship as much product). If you need to do something that's not just generic CRUD app/site... picking an exotic technology that high-powered programmers love, might make it easier to hire. Compare: "We're building a gig economy app to clean gas station bathrooms, and we eat our own dogfood!" to: "We're USING RUST to build something (not a crypto scam, honest), and WE WILL PAY YOU MONEY TO HACK RUST, and did we mention RUST!!!"
- hbrn 4y ago
  Latter has a risk of attracting fanboys and detracting product engineers.
  - Klonoar 4y ago
    Not in my experience.
- habibur 4y ago
  Leave it upto what engineers want, and they will try to build a google scale thing to put it into their resume.
- makeitdouble 4y ago
  I’m curious about the hierarchy between crypto scams and gig economy bathroom cleaning apps. That aside, finding warm bodies to fill a position is usually not the problem, they need to actually help your product grow. Focusing on the technology prominently is like hiring security guards by touting the big guns they’ll get. You’ll be rolling the dice on the people that come to you for the position.
- ParetoOptimal 4y ago
  I've seen this happen with Haskell for web backends for instance.
  - neilv 4y ago
    It's also been known to happen with Common Lisp and Scheme.
phkahler 4y ago
Crypto, blockchain, web 2.0, monetization. When the company is the product, any trendy buzzword helps to sell, even if its actively harmful to the "user".
brap 4y ago
So often I see SaaS companies write things like “built with Rust”. Yeah, nobody cares!
- bbkane 4y ago
  Customers might not, but it's probably effective recruiting.
agentultra 4y ago
Put another way, startups are trying to find a way to exploit a market niche as fast as possible. They happen to use software to do it. They’re (usually) not in the business of engineering. I say usually because some startups are building new computers, libraries, and software infrastructure and care a lot about things that SV-style startups don’t. Which means: this isn’t universally true advice. If I’m buying a new computing system from you I’m certainly interested in your tech stack and it will be a key feature. But if your business is getting people to buy more things they don’t need then yeah, use a batch script and some spreadsheets if that gets you to market faster.
ChrisMarshallNY 4y ago
It's funny. I'm working, right now, on a modular SDK that is the "heart" of an iOS app that we've been developing for a couple of years. I've taken functionality that was distributed all over a 30-screen iOS app, and distilled it into a simple-to-use, platform-agnostic SDK. This gives us a "kernel" that drastically improves the flexibility, quality, performance, and aesthetics of the app. It's a thing of beauty. And absolutely no one but me, cares. That's exactly what I want. I'm a little bit butthurt that no one wants to gaze in adoration at my cool toy, but it's not open-source (as if that would even matter, as I've discovered that no one actually ever seems to look at open-source code). The app will work much better, as a result of the work that I've been doing for the last couple of months.
- llanowarelves 4y ago
  I also prefer this way. People sometimes complain that software engineering isn't real engineering then push back on components like these, preferring hairball duct tape for short-term business reasons, which isn't exactly the quality that German and Japanese engineering have.
- nullsense 4y ago
  We've never met and we probably never will, and it's a virtual certainty I'll never see the code of which you speak. But know this... I appreciate it. And I can imagine it. I certainly empathize with your plight. The feeling of a job well done is all the validation you need.
  - vipermark7 4y ago
    Blessed comment! :D
- e_i_pi_2 4y ago
  > (as if that would even matter, as I've discovered that no one actually ever seems to look at open-source code) I _really_ wish our company would open-source the code just as a way to make the team feel better and hold ourselves to a higher standard. I know no one will actually read it unless they're trying to find a vulnerability - and that would only improve the product! But even with a restrictive license the company is concerned about "trade secret"/"intellectual property" stuff. Personally I feel like if we figured out some tricky problem other people have then we have an ethical duty to share it with the community
prankbudgetio 4y ago
[flagged]
cratermoon 4y ago
I joined a somewhat troubled project a year after it's initiation. One of the things I learned is that early on, while the stakeholders were looking for visible progress, the tech lead decided to give them a presentation on the state of the system. What the stakeholders were concerned about was that they had not seen even a kernel of a working system. The tech lead, I'm told, focused on the tech stack, the implementation details, the integration points with existing systems, and a whole bunch of things that had the stakeholders dozing off within a short time. I think the only reason project wasn't cancelled there and then was because it was in a critical path for the business. I 100% believe that the tech lead gave this presentation, because part of my onboarding, such as it was, went over pretty much all the technical details of how the system was built, but never did I really get a sense of what the goals were, what functionality was in place, or any overall understanding of what all the pieces were supposed to be doing. Yeah, ok, it's great that you created a bunch of code using gRPC to communicate internally and connected up to bunch of REST backend services sending and receiving JSON, but so what? How did any of that address the functional needs of the stakeholders?
asp_hornet 4y ago
> No; customers are not paying for, nor give a shit about, these things. Sorry. It’s still cool stuff. It’s just not what you’re selling They sort of are if your bad architecture means features are slower to roll out than your competitors and each release introduces bugs and regressions.
chrismsimpson 4y ago
Unless of course your product is the stack
ETHisso2017 4y ago
Counterpoint: Slack
- selcuka 4y ago
  How is it a counterpoint? I don't know what technology(ies) Slack uses (except maybe the desktop client, which is obviously Electron) and I don't care.
- berkle4455 4y ago
  Counterpoint to what? Slack runs on PHP. I'm sure it has hosted innumerable discussions by typescript or ruby fanatics linking the fractal-of-bad-design article and patting themselves on the back while clicking the fuck out of that :fire: emoji in response.
bobleeswagger 4y ago
Most tech stacks are a liability, it's not talked about enough.
ummonk 4y ago
I don’t disagree with the sentiment and point of the article. That said, I’d argue that if as a startup you believe you’re probably going to quickly and easily achieve product market fit, it is perfectly rational to focus on laying the right technical foundations so you don’t end up saddled with tech debt down the road. Once the product has become complex, rewrites are incredibly hard. And there are multibillion dollar companies out there dealing with the consequences of a tech decision a founder made in the first month of development while being focused on finding product market fit.
- yowlingcat 4y ago
  Sure. I think I'd maybe go one step further than the headline and say that for startups, unless it is what you are explicitly building from scratch and selling, your tech stack should never be the product. Laying the right technical foundations shouldn't be difficult -- it should be generally be picking the most boring[1], dependable choices that you've been able to rely upon in the past. [1] https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology
  - ummonk 4y ago
    I had a pretty negative reaction to that title but completely agree with the post (and largely with the example choices). I think I'd rephrase it more as "choose proven technology", cause "boring" to me conjures up images of Java hell.
blitz_skull 4y ago
Counter-point—If your stack isn't ergonomic, you're going to ship less product. Don't spend all your time fretting about your stack, but definitely make it delightful to work with.
victor106 4y ago
Amazon’s tech stack did become the product
rektide 4y ago
This is true only because there is a huge wall between users & devs. Indeed: that's a safe bet for the foreseeable. But over time, for some... I strongly want to believe that malleable software will find a niche and grow it. Expert users are a sight to behold, even with the limited offerings we have about, be it IFTTT, Excel, apple/windows automation tools, or what-have you. If a system can actively work to onboard, to layer it's complexity, to make it's flows observable & hackable, there's a good chance we could start emerging new kinds of power users, could start onboarding more people into software & systems literacy, in a non-overwhelming & fun way. The web has a hackability like this, that is joyous: writing a small userscript to tweak or rework a site to your own pleasure can be phenomally easy & fun, is a great way to get folls started with & enjoying computing. Again, the advice here is good. Most people are not trying to strike at the roots of human-computing interaction. But some folks should be, knowingly, with intent to make open, transparent, hackable software. Soft software. And in these cases, the stack matters enormously, is the truthful reality behind the obfuscating veil of interface. Efforts like Naked Objects are about more honest systems, and when we invite the user in, invite them to our level, bestow real power upon them, these invisible opinions implicit in our stack become much more the shape of the thing.
yawnxyz 4y ago
Well, I just built and launched an HN-like headless forum system running on Sveltekit, Vercel and Airtable. There's not really any CI or microservices or anything cool. Of course it's not scalable. Is it secure? Probably not... All the account information is just stored on Airtable! BUT this is a system I know, and inspecting and changing data is so easy on Airtable. Managing content is ultra fast. And no, the Airtable API is slow as mud and which is causing my project to be slow as mud. HOWEVER, I launched this version very quickly. Much quicker than doing it on Supabase or SQLite or whatever... because I'm a designer, and it's hard for me to get started on those platforms. If this takes off, somehow, then I'll worry about scaling later. Right now I've got a product to launch (and sell)!
kodah 4y ago
> A mindset of technology being the means, not the end, is uncomfortable. But it will help you stay focused on what matters most (the product and your customers), avoid wasteful misadventures, and maximize the company’s chance of success. I'm wary when I hear this sentiment. At the heart of very versatile companies is a definition of what makes them who they are, both in a product sense and a technical sense. I've worked at very successful companies that wrote their own networking stacks, load balancers, cryptography, service catalogs, paging systems, etc... The stark views of fully embracing a Not Built Here mentality and the "build product and product only" are broken for me. I think executives make bets that authorizing a certain project will add to their direct and marginal gains. Direct gains being cost, performance, ease of use (UX/DX), etc... Marginal gains being the experiences that add up over time building custom things or being able to leverage the fully custom parts of your stack. If all you care to have expertise in is the product people see you'll miss the products that make that product faster, more secure, and easier to maintain long term.
nunez 4y ago
this post reminds me of the dude that wrote plentyoffish, the worst's worst looking dating site, in like ASP.NET or something and was able to sell it for hundreds of millions because basically everyone used it or craigslist i like new tech quite a lot but so much of this stuff are solutions looking for problems
satvikpendem 4y ago
Or said another way: We rewrote everything in $HOTLANG and our startup still failed [0] Some amazing satire on this exact topic. [0] https://news.ycombinator.com/item?id=33555197 https://news.ycombinator.com/item?id=33555197
migf 4y ago
I think this is really misguided. While it's true that the stack just enables you build something for people, if you just chase market you have a good chance of piling up technical debt and slowing down before you get there. I have seen far too many projects take twice or five times as much budget as needed because people didn't know what they were doing from the get go. Greenfield applications should start with a rough idea of what the technical requirements will be (what ordr of magnitude of users / transactions per second) and start by cloning a reference implementation that does what's needed. Otherwise you will never get ahead of product.

256 points by brendannee 4y ago

[flagged]

Most of the stuff we used is based on some very boring tech. It may get upgraded to something fancy when the product/service scales to a significant number of users, but Spring+Postgres (or RoR, or Django, or PHP...) will get you there with no problems. Facebook was PHP, Instagram was Django etc. They became what they became while using incredibly boring "old-school" tech. The product is paramount, not the tech.

ummonk 4y ago
I mean, Facebook ended up forking PHP and writing their own type system and execution environment to make it work after they had scaled up...
- dmitriid 4y ago
  Keyword: after they scaled up. First they became Facebook :)

cudgy 4y ago

This is why myopic technical founders need a balanced partner to help recognize the blending of company mission and company implementation. However, it is natural for a myopic technical person to want to leverage their existing skillset, as this knowledge represents to them the key value that they bring to the organization. Unfortunately, blind loyalty to technical stacks is not likely to be an advantage, long-term. The ability to balance the need to leverage existing skills and taking advantage of new skills is critical.

PaybackTony 4y ago

This is something I preach often, even at FAANG. Often engineers feel comfortable and in-the-zone when solving for a process. One saying I often delivery is: Engineers often think their job is to build things. That's not the whole story, they build things for _people_. Nobody cares what your code looks like. Nobody cares what your architecture looks like. As engineers we should worry about creating forgettable experiences (at least in enterprise). They care that it does the job well, with low load times and an easy to use UX. That's it. If you did your job right they'll forget that software helped them do their job or complete their task faster / better because the experience was so seamless they spent the entire time focused on their own goal, and not how to navigate your software to get there. How you get there is irrelevant. Now it's your job as an experienced and intelligent engineer to make quick, thoughtful decisions on how to get your product to where it needs to be so that your _customers_ can create more impact on their own business / lives faster.

deleted 4y ago
[deleted]
quanticle 4y ago
Nobody cares what your code looks like. Nobody cares what your architecture looks like. … until it breaks. Nobody cared how the FAA NOTAM database was implemented either, until it went down. Part of being a professional engineer is thinking about these things, so your users won't have to.
- AnIdiotOnTheNet 4y ago
  Forgive me if I'm wrong about this, but it would seem to me that the FAA NOTAM system had orders of magnitude more uptime than literally any product produced by so called "professional" "engineers" at big software companies.
  - alfalfasprout 4y ago
    I think the point still stands but in a different way. The architecture was designed to be quite reliable.

deleted 4y ago

[deleted]

habitue 4y ago

> customers are not paying for, nor give a shit about, these things. Yes, but they do give a shit if: - your product is slow, so they assume it's crap and leave your site - your product breaks, no one notices or fixes it - your product is bad, because your wrote it in a safe boring technology like cobol and therefore couldn't access the best developers. (exaggeration, but variations on this are true) My point isn't that you must use the newest shiniest tech and infra to do everything, my point is that when people write blog posts like this, they want to make it seem like there's a clear line between what's "cool shiny tech" and what's "hard nosed business focused shipping". In reality, it's a lot fuzzier and these things feed back into each other. For example, you shipped bad code early on to get velocity, but it turned out to be foundational and hard to replace, so your best developers leave as your codebase becomes a ball of mud that it's become clear will never be fixed. So now your worst developers are working on a ball of mud and making it worse... etc etc. As always, the answer is that this stuff is hard, and you can't make a technology decision by just considering things a user wants to buy and saying everything else is navel gazing and messing around.

iLoveOncall 4y ago
> - your product is slow, so they assume it's crap and leave your site I don't think there any tech stack that will have any significant (or even just measurable) impact the speed of the product, for 99% of the startups. > - your product breaks, no one notices or fixes it This has nothing to do with the tech stack. You can setup monitoring, alarms and metrics for any tech stack. > - your product is bad, because your wrote it in a boring technology like cobol and therefore couldn't access the best developers. 99% of startups won't be able to afford the best developers anyway. 99% of startups don't need the best developers. Average developers can make great products. --- You are taking "your tech stack does not matter" and twist it into "You will have problems if you have the worst tech stack and the worst developers!". Cool, but that's not what the article is about.
- habitue 4y ago
  > your tech stack does not matter > You will have problems if you have the worst tech stack Cool, so we've established that I'm saying the tech stack matters. All of the problems above have to do with the tech stack. Yes performance is part of your tech stack. Yes, how easily you can monitor it and is part of your tech stack. > 99% of startups won't be able to afford the best developers anyway. 99% of startups don't need the best developers. Average developers can make great products. Here again, the tech stack matters. If you have known mediocre developers, you should pick a language like Java or Go because otherwise it's going to be a mess. If you have good developers, you should trust them to pick the technologies.

bcrosby95 4y ago

> Why is Joe’s closet computer a bad choice? Because it’s a single point of failure and we won’t be able to ship fast if it breaks, which it will. It's kinda a shame they reduced it to this. A single machine in a colo center is going to be far more reliable than single availability zone in AWS, which is all many people resort to. And maybe we've just gotten lucky, but in general our very simple 20 machine colo center setup has been more reliable than our single region AWS setup. But yeah, if you literally put Joe's computer in a closet it isn't gonna be too reliable for all sorts of reasons completely unrelated to the reliability of modern computer hardware.

andrewmutz 4y ago
I think he literally means Joe's computer closet. Colo is fine if you can set it up extremely quickly and it takes minimal ongoing support time. Depending on what you mean by Colo, that may or may not be possible.
themitigating 4y ago
"It's kinda a shame they reduced it to this. A single machine in a colo center is going to be far more reliable than single availability zone" I think that depends on the colo honestly. What is so unreliable about a single EC2 instance in a zone?
- arcturus17 4y ago
  Yea I’m left scratching my head too. Is there really a difference in reliability between an EC2 instance and colocated hardware?
  - mrkurt 4y ago
    Yes. In my experience, it's substantial. 200 servers in colo == maybe 1 failure every 6 months. 200 EC2 instances, one per month. These are different things, though. If you're using AWS, you would build to account for this.
    - 4y ago

pickledish 4y ago

I have to say I agree very much with his point, though not really the way he communicates it: > Let’s riff. I’ve had my “macho engineer” days, I’ve built that stuff. Take me deep, I’m ready. or > No; customers are not paying for, nor give a shit about, these things. Sorry. Just feels to me a bit condescending for no reason

mik3y 4y ago
(author here) Fair feedback, thanks! I wrote that with myself as the listener in mind -- I often need the reminder that is the post's title -- but I can see how the delivery would sound abrasive to another reader. Gave it a light edit.

0xdeadbeefbabe 4y ago

> A mindset of technology being the means, not the end, is uncomfortable. Really? That's pretty funny. How could anyone miss this lesson who has ever used a computer to do things.

cirrus3 4y ago
It is less funny once you've been exposed to these people frequently. I assure you they are out there, and yes they have used computers to do thing in the past, yet they behave this way still. This is kind of the point of the article.

Barrin92 4y ago

Very good post. A few years ago there was an interesting post linked here on HN about Stackoverflow's tech stack and I was surprised how simple it was. Basically a bunch of servers cache, load balancer, dotnet, sql. And in reality for most projects that is honestly just about what you need.

neilv 4y ago

> If we pick exotic technology, it’ll be harder to hire (and we won’t ship as much product). If you need to do something that's not just generic CRUD app/site... picking an exotic technology that high-powered programmers love, might make it easier to hire. Compare: "We're building a gig economy app to clean gas station bathrooms, and we eat our own dogfood!" to: "We're USING RUST to build something (not a crypto scam, honest), and WE WILL PAY YOU MONEY TO HACK RUST, and did we mention RUST!!!"

hbrn 4y ago
Latter has a risk of attracting fanboys and detracting product engineers.
- Klonoar 4y ago
  Not in my experience.
habibur 4y ago
Leave it upto what engineers want, and they will try to build a google scale thing to put it into their resume.
makeitdouble 4y ago
I’m curious about the hierarchy between crypto scams and gig economy bathroom cleaning apps. That aside, finding warm bodies to fill a position is usually not the problem, they need to actually help your product grow. Focusing on the technology prominently is like hiring security guards by touting the big guns they’ll get. You’ll be rolling the dice on the people that come to you for the position.
ParetoOptimal 4y ago
I've seen this happen with Haskell for web backends for instance.
- neilv 4y ago
  It's also been known to happen with Common Lisp and Scheme.

phkahler 4y ago

Crypto, blockchain, web 2.0, monetization. When the company is the product, any trendy buzzword helps to sell, even if its actively harmful to the "user".

brap 4y ago

So often I see SaaS companies write things like “built with Rust”. Yeah, nobody cares!

bbkane 4y ago
Customers might not, but it's probably effective recruiting.

agentultra 4y ago

Put another way, startups are trying to find a way to exploit a market niche as fast as possible. They happen to use software to do it. They’re (usually) not in the business of engineering. I say usually because some startups are building new computers, libraries, and software infrastructure and care a lot about things that SV-style startups don’t. Which means: this isn’t universally true advice. If I’m buying a new computing system from you I’m certainly interested in your tech stack and it will be a key feature. But if your business is getting people to buy more things they don’t need then yeah, use a batch script and some spreadsheets if that gets you to market faster.

ChrisMarshallNY 4y ago

It's funny. I'm working, right now, on a modular SDK that is the "heart" of an iOS app that we've been developing for a couple of years. I've taken functionality that was distributed all over a 30-screen iOS app, and distilled it into a simple-to-use, platform-agnostic SDK. This gives us a "kernel" that drastically improves the flexibility, quality, performance, and aesthetics of the app. It's a thing of beauty. And absolutely no one but me, cares. That's exactly what I want. I'm a little bit butthurt that no one wants to gaze in adoration at my cool toy, but it's not open-source (as if that would even matter, as I've discovered that no one actually ever seems to look at open-source code). The app will work much better, as a result of the work that I've been doing for the last couple of months.

llanowarelves 4y ago
I also prefer this way. People sometimes complain that software engineering isn't real engineering then push back on components like these, preferring hairball duct tape for short-term business reasons, which isn't exactly the quality that German and Japanese engineering have.
nullsense 4y ago
We've never met and we probably never will, and it's a virtual certainty I'll never see the code of which you speak. But know this... I appreciate it. And I can imagine it. I certainly empathize with your plight. The feeling of a job well done is all the validation you need.
- vipermark7 4y ago
  Blessed comment! :D
e_i_pi_2 4y ago
> (as if that would even matter, as I've discovered that no one actually ever seems to look at open-source code) I _really_ wish our company would open-source the code just as a way to make the team feel better and hold ourselves to a higher standard. I know no one will actually read it unless they're trying to find a vulnerability - and that would only improve the product! But even with a restrictive license the company is concerned about "trade secret"/"intellectual property" stuff. Personally I feel like if we figured out some tricky problem other people have then we have an ethical duty to share it with the community

prankbudgetio 4y ago

[flagged]

cratermoon 4y ago

I joined a somewhat troubled project a year after it's initiation. One of the things I learned is that early on, while the stakeholders were looking for visible progress, the tech lead decided to give them a presentation on the state of the system. What the stakeholders were concerned about was that they had not seen even a kernel of a working system. The tech lead, I'm told, focused on the tech stack, the implementation details, the integration points with existing systems, and a whole bunch of things that had the stakeholders dozing off within a short time. I think the only reason project wasn't cancelled there and then was because it was in a critical path for the business. I 100% believe that the tech lead gave this presentation, because part of my onboarding, such as it was, went over pretty much all the technical details of how the system was built, but never did I really get a sense of what the goals were, what functionality was in place, or any overall understanding of what all the pieces were supposed to be doing. Yeah, ok, it's great that you created a bunch of code using gRPC to communicate internally and connected up to bunch of REST backend services sending and receiving JSON, but so what? How did any of that address the functional needs of the stakeholders?

asp_hornet 4y ago

> No; customers are not paying for, nor give a shit about, these things. Sorry. It’s still cool stuff. It’s just not what you’re selling They sort of are if your bad architecture means features are slower to roll out than your competitors and each release introduces bugs and regressions.

chrismsimpson 4y ago

Unless of course your product is the stack

ETHisso2017 4y ago

Counterpoint: Slack

selcuka 4y ago
How is it a counterpoint? I don't know what technology(ies) Slack uses (except maybe the desktop client, which is obviously Electron) and I don't care.
berkle4455 4y ago
Counterpoint to what? Slack runs on PHP. I'm sure it has hosted innumerable discussions by typescript or ruby fanatics linking the fractal-of-bad-design article and patting themselves on the back while clicking the fuck out of that :fire: emoji in response.

bobleeswagger 4y ago

Most tech stacks are a liability, it's not talked about enough.

ummonk 4y ago

I don’t disagree with the sentiment and point of the article. That said, I’d argue that if as a startup you believe you’re probably going to quickly and easily achieve product market fit, it is perfectly rational to focus on laying the right technical foundations so you don’t end up saddled with tech debt down the road. Once the product has become complex, rewrites are incredibly hard. And there are multibillion dollar companies out there dealing with the consequences of a tech decision a founder made in the first month of development while being focused on finding product market fit.

yowlingcat 4y ago
Sure. I think I'd maybe go one step further than the headline and say that for startups, unless it is what you are explicitly building from scratch and selling, your tech stack should never be the product. Laying the right technical foundations shouldn't be difficult -- it should be generally be picking the most boring[1], dependable choices that you've been able to rely upon in the past. [1] https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology
- ummonk 4y ago
  I had a pretty negative reaction to that title but completely agree with the post (and largely with the example choices). I think I'd rephrase it more as "choose proven technology", cause "boring" to me conjures up images of Java hell.

blitz_skull 4y ago

Counter-point—If your stack isn't ergonomic, you're going to ship less product. Don't spend all your time fretting about your stack, but definitely make it delightful to work with.

victor106 4y ago

Amazon’s tech stack did become the product

rektide 4y ago

This is true only because there is a huge wall between users & devs. Indeed: that's a safe bet for the foreseeable. But over time, for some... I strongly want to believe that malleable software will find a niche and grow it. Expert users are a sight to behold, even with the limited offerings we have about, be it IFTTT, Excel, apple/windows automation tools, or what-have you. If a system can actively work to onboard, to layer it's complexity, to make it's flows observable & hackable, there's a good chance we could start emerging new kinds of power users, could start onboarding more people into software & systems literacy, in a non-overwhelming & fun way. The web has a hackability like this, that is joyous: writing a small userscript to tweak or rework a site to your own pleasure can be phenomally easy & fun, is a great way to get folls started with & enjoying computing. Again, the advice here is good. Most people are not trying to strike at the roots of human-computing interaction. But some folks should be, knowingly, with intent to make open, transparent, hackable software. Soft software. And in these cases, the stack matters enormously, is the truthful reality behind the obfuscating veil of interface. Efforts like Naked Objects are about more honest systems, and when we invite the user in, invite them to our level, bestow real power upon them, these invisible opinions implicit in our stack become much more the shape of the thing.

yawnxyz 4y ago

Well, I just built and launched an HN-like headless forum system running on Sveltekit, Vercel and Airtable. There's not really any CI or microservices or anything cool. Of course it's not scalable. Is it secure? Probably not... All the account information is just stored on Airtable! BUT this is a system I know, and inspecting and changing data is so easy on Airtable. Managing content is ultra fast. And no, the Airtable API is slow as mud and which is causing my project to be slow as mud. HOWEVER, I launched this version very quickly. Much quicker than doing it on Supabase or SQLite or whatever... because I'm a designer, and it's hard for me to get started on those platforms. If this takes off, somehow, then I'll worry about scaling later. Right now I've got a product to launch (and sell)!

kodah 4y ago

> A mindset of technology being the means, not the end, is uncomfortable. But it will help you stay focused on what matters most (the product and your customers), avoid wasteful misadventures, and maximize the company’s chance of success. I'm wary when I hear this sentiment. At the heart of very versatile companies is a definition of what makes them who they are, both in a product sense and a technical sense. I've worked at very successful companies that wrote their own networking stacks, load balancers, cryptography, service catalogs, paging systems, etc... The stark views of fully embracing a Not Built Here mentality and the "build product and product only" are broken for me. I think executives make bets that authorizing a certain project will add to their direct and marginal gains. Direct gains being cost, performance, ease of use (UX/DX), etc... Marginal gains being the experiences that add up over time building custom things or being able to leverage the fully custom parts of your stack. If all you care to have expertise in is the product people see you'll miss the products that make that product faster, more secure, and easier to maintain long term.

nunez 4y ago

this post reminds me of the dude that wrote plentyoffish, the worst's worst looking dating site, in like ASP.NET or something and was able to sell it for hundreds of millions because basically everyone used it or craigslist i like new tech quite a lot but so much of this stuff are solutions looking for problems

satvikpendem 4y ago

Or said another way: We rewrote everything in $HOTLANG and our startup still failed [0] Some amazing satire on this exact topic. [0] https://news.ycombinator.com/item?id=33555197 https://news.ycombinator.com/item?id=33555197

migf 4y ago

I think this is really misguided. While it's true that the stack just enables you build something for people, if you just chase market you have a good chance of piling up technical debt and slowing down before you get there. I have seen far too many projects take twice or five times as much budget as needed because people didn't know what they were doing from the get go. Greenfield applications should start with a rough idea of what the technical requirements will be (what ordr of magnitude of users / transactions per second) and start by cloning a reference implementation that does what's needed. Otherwise you will never get ahead of product.