Your tech stack is not the product | Hacker News Reader

Your tech stack is not the product

hoho.com

256 pointsbrendannee123 comments

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.

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.

Blessed comment! :D

> as if that would even matter, as I've discovered that no one actually ever seems to look at open-source code

there are 3 circumstances in which i regularly look at open-source code:

a. i want to fix a bug or improve some rough UX.

b. i want to add new functionality.

c. i want to borrow something from it for use elsewhere.

you’re right that the better your code, the less likely i am to read it for reason (a). and the more sophisticated your code, the less likely i am to read it for (c), as i’ll be hunting for reusable libraries rather than cribbing directly from applications.

but consider that for any commercial product, i’m also less likely to read the code for reason (b) because of largely unwritten cultural norms (if i contribute code to a project that has paid devs and don’t get paid for that, it feels like i’ve been suckered).

this being an iOS app exacerbates all this because even if i find a bug and suspect a one-line fix that would be worth my time, i won’t pursue it because i have absolutely no idea how to deploy my patched version (i have to register with app store, maybe pay some licenses/fees, does Apple even allow me to distribute patched versions of someone else’s software?)

so, yeah, you’re not wrong, but you’re also working in a context that really amplifies what you witness around open source (and if you specifically want your beautiful code to be read by others maybe this shows which approaches are more/less likely to get that).

> (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

Hey, if you write a blog post on this I'd totally read it! Are you writing something that exposes a C API so you can embed it on various platforms?

I’ve written a bunch of stuff, over the years. Most can be found here[0]. I haven’t done much in a while, but I do want to get back to it. It’s just that my dance card has been a bit full.

The app has had a fairly long and winding trajectory. Most of the reason that it’s taken this long, is because the other stakeholders really didn’t know what they wanted, when we started, so the project kind of “accreted.” It’s really been a long prototype phase. Much better than an MVP, because we were free to make massive changes, whenever we wanted. It has a couple of backends, but they have been stable for years. Most of the thrashing has been on the UI.

The last few months, the functionality has stabilized to the point that I could factor out this SDK, and things will move very quickly, from here.

We’ll see what I can write, once I can come up for air.

[0] https://littlegreenviper.com/miscellany/

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.

The reaction to the post was ... interesting ... I didn't make the post as any kind of complaint. It was a fairly simple statement of fact. I don't actually require any validation. I'm pretty comfortable with what I can (and can't) do.

It's a closed-source app, and probably no one will ever see the source. I don't expect them to. I have plenty of other code that folks can look at, if they want. A lot of that code is actually integrated into the app (I use lots of dependencies; just mostly ones that I've written).

I was really mentioning that the stack doesn't matter to most of the stakeholders on the project, and I'm fine with that. It's the way that it's supposed to be.

Oh, and it's an SDK, not a framework. It happens to have most of the app operation embedded in it, but the framework is UIKit. Any Apple dev of reasonable skill would be able to take it and run. They should have some skill and experience, though, or they are likely to make a hash of things; with or without the SDK.

>I'm a little bit butthurt that no one wants to gaze in adoration at my cool toy

That's life. Did you call up the bus company and thank them for engineering a bus to get you to work safely?

No, but some guy somewhere has dozens of model buses lined up in a basement where he lovingly paints tiny details on them while listening to Bus Stop Announcement ASMR

Hah, there are also various bus simulator games out there, trucking games and for some reason trains especially.

Not just tycoon games (like Transport Fever) but also ones that focus a lot on the details (Euro Truck Simulator seems to be a big one).

While we take lots of things for granted, there are always niche communities and people who like all of the details and whatnot.

It's very much the same how many might use languages without caring about how the GC works (where applicable) or use frameworks without caring about their internals, because they don't have to. And then there are those who do deep dives and sometimes come up with nice improvements or even just articles or videos about that stuff.

It's quite cool.

Not going to lie, that sounds completely awesome.

It was really a joke. I was sort of making fun of myself.

In retrospect, it seems to have fallen flat.

FWIW, I got it the way I am pretty sure you had intended it <3.

My worry over a case like this would be if your boss, or more likely, the nontechnical middle management stakeholders up the food chain, start asking “so what have you been doing the past few months (to justify your continued employment or bonus)?”

This would depend on your company culture of course.

I look at open-source to learn new programming languages, especially their idioms.

And then you leave and everyone has to deal with your homegrown framework.

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.

    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.

Nobody cares if your warehouse is neat and clean. Your customers never go in there. They just receive orders that are shipped out of it.

But if your warehouse is a mess, if the aisles of your warehouse are blocked by crates strewn everywhere (that you've been meaning to put away for ages), then it does matter if your warehouse is neat and clean because it takes forever to maneuver your forklift in to retrieve products to ship them out. If your warehouse is disorganized, and you can't find anything when you need it, then it matters.

The real trouble, I think, is when people have reasons to choose not to keep the warehouse organized and functioning smoothly (like workers who see it as drudgery or managers who want workers working on something else) and they try to excuse it by saying, "Our customers never visit."

(I don't think the person above is doing that, incidentally. I think they're just agreeing with the keep your eyes on the prize message.)

The difference between software and most other forms of engineering is that the internals of software are invisible to everyone but the developers. A manager walks in to the warehouse you describe above and goes “what in the literal hell? No one goes home until we clean this $&@$ up!”. A machine that has been poorly designed looks like a piece crap.

Software, if the UI looks nice the massive tangled mess inside is completely invisible to customer and manager alike. Gross inefficiencies, evil hacks, everything entangled with everything? No one can see it. “Why does it take 3 months for a tiny feature?” “Technical debt”, “ok, you can have 5% of your time budget to sort that out”…

If people could really see the software, viscerally, they would approve budgets to fix it.

> If people could really see the software, viscerally, they would approve budgets to fix it.

Tools for this exist; ex: https://semgrep.dev/docs/writing-rules/data-flow/data-flow-o...

I suspect the information overload for any substantially large code base would be such that, non-engineers would look right past the complexity after the enthusiasm wears off.

Technical managers do look at code...they often don't really "see" the problems until they try to implement something tho.

Yeah the best way to understand software (maybe even the only way) is to try to do something with it.

Yep, this here.

I work with a product that sees a massive difference in use between the low end customers and the very highest end of customers. For the low end customers it doesn't matter what your architecture is at all. Could be a single small machine in a closet and it would suffice.

For our large customers it matters 100%. They are doing throughput 4 to 5 orders of magnitude higher than our most basic customers per day. They will push NAS and database performance to the limit. Every time we think "eh, no one is going to do that much" our customers come back and prove us wrong. Databases expand to billions and billions of rows. Query performance falls apart. Design decisions lead to lack of ability of horizontal scaling.

And when the systems get to this size the costs of operating the system add up quickly, and if your competitors choices lead to much lower operational costs, then expect to lose customers to them, especially as your product equalizes in capability, or at least meets their set of needs.

The argument is that nobody cares if you use a single file with 10K LOC of outdated JavaScript code or a beautiful Rust library to compute whatever.

Of course customers care about performance - if your app is unusably slow it is going to be an issue.

The risk of focusing on code and architecture too much is that it will never break. Not because it's very reliable: because you have no users.

Part of being a professional engineer is recognizing that your knowledge is always limited. No matter how much you think about these things, they will always break. Being too careful is as bad as being reckless.

Instead of trying to prevent failure, accept that it's inevitable and make sure you are fast at detecting and fixing.

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.

I think the point still stands but in a different way. The architecture was designed to be quite reliable.

More than google.com? Maybe, but it's close. Also, I'd be surprised if those behind NOTAM were all "professional engineers" since software PEs are pretty rare, relatively speaking. Especially in the US.

You're comparing database to a service. NOTAM is real-time, google.com is not.

By that standard google.com is always down.

It would seem to me that the FAA NOTAM system had professional engineers working on it to produce that uptime.

If it wasn't then who built it? Or is it the quotes we should focus on.

Sure, but we do make intentional tradeoffs, at least sometimes.

AWS uptime is pretty insane

According to their own status page, yes

yes, some part of aws somewhere is always online.

fully functional? 7.12.2021 alone was enough to kill that statement for the next few years.

While not wrong, everything breaks at scale. Everything. Anyone that says otherwise is just not interested in talking about where what they built will break.

And note that this is more than just scale of use. It is also scale of development. Keep adding changes to something, and it will break. Stability of application requiring stability of development is just not something we care to admit, that often.

That is, don't hide when/why something will break. But also don't get blinded looking for how to avoid all breakage. If you can, find ways to isolate failures and block off entire sections.

> everything breaks at scale

This is good advice. You should be aware of who you are building for. Designing your system to run on 100 containers orchestrated by Kubernetes is overkill for your average SaaS MVP, while counting on shell scripts is a recipe for disaster at FAANG scale. Scale matters.

Don't just look at the execution you are building for, but also the team that will be maintaining it. That is, there are several values for "who" that you are building for. Each will have cause for you to reach to more complicated seeming solutions, as you go.

> … until it breaks.

My boss once told me, "[toast0], you can't have that kind of attitude if your shit doesn't work"

Rather than change my attitude, I made sure my shit worked.

My point on this isn't that you should write ugly, unmaintainable code because who cares. It's that, if you're an experienced and intelligent engineer, you're going to do just fine. There's no need to complicate it, get lost in analysis paralysis and so forth. I have seen top engineering teams make software that's hard to maintain with questionable performance as a _result_ of some of the things this article brings up. Often times too much engineering is just as bad as not enough.

Here is how I personally define good software engineering:

- Does it do the job? - Is there low cognitive load in regards to following the code? (Can you jump back in the code in 6 months and get your feet quickly... AKA: Don't over-abstract). - Is it performant? - Can you easily make changes?

If those 4 things are true, the rest doesn't matter from my experience.

For each case like NOTAM database going down, there are tens of thousands of applications running on the web and outside the web without people obsessing about its architecture.

yeah but that's borrowing trouble.

we can spend ages solving every theoretical.

and to be fair NOTAMs were rock solid until that happened, so if anything this failure was a good thing long-term

> 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.

Isn't this sneakily hiding the assumption that what your code and architecture looks like has no effect on how good/fast your product is? That's a pretty common implicit sentiment these days, especially as part of the (valid) sentiment that chasing fad languages/frameworks/tools is not a good idea. But it's pretty clearly not true in general.

I believe the author's point is that you should care about the relation between your technical decisions and actual benefits for the user. It is true that many technical people develop an appreciation for tech choices that is driven by aesthetics more than by actual impact.

That being said, caring too much about customer success also has its pitfall, businesses can be driven by the present more than by the future, and by low-impact guaranteed results more than high-impact hypothetical risks.

The retort would be that your fellow engineers are also user/consumers of your code.

You’re building code that others will review, run, modify and rely on. They are people too and you should care about them and their needs.

The article is entire about the ways that your code and architecture affects the final product. Really, there is no other thing there than the complete opposite of your complaint.

The next engineer working on the code will care about what it looks like.

Good architecture leads to faster feature development and increased stability, which makes your users happy

The point is that is just one strategy not the goal.

> Nobody cares what your code looks like. Nobody cares what your architecture looks like.

Do I not count as somebody? ;)

> 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.

Quick and thoughtful are often in tension. Sometimes you really do need to take a step back and take the 10000 foot view and think about your systemic challenges. It may be worth investing in a new architecture that will allow you to iterate faster and make quicker, better decisions in the future. The first instinct should of course always be to try do the smallest thing within the limitations of the current system to deliver customer value, but there are times when you are spending so much time fighting the system, that it is a wise strategic investment to rearchitect. It takes significant maturity as a developer to recognize the difference between this type of investment and hype-driven churn.

There are always going to be the kind of developers (often quite smart and idealistic but relatively inexperienced) who are easily susceptible to hype, discover a shiny new toy and want to rewrite everything in its image. This type of developer can waste a huge amount of time, both their own and of their colleagues, engaging in fruitless technical debate.

Also, it is not just the customer who matters. You as the developer also matter. If you hate the system you are working with so much that you desperately want to rearchitect it, you either should find a way to do that or leave the project/company regardless of whether you are able to provide value for customer.

This makes perfect sense for founders/c-level people, and owners in general.

But here is the employee paradox: He may sooner or later shift his main focus from customers to his own career. So he reinvents the wheel building the next level hot js framework, start measuring his goals in Github stars and conference bookings...

In short, his tech stack IS the product, again.

This is one of the best comments ever in HN. Every engineer should understand this. Users don't care about what's behind. They care about whether it works and its easy. All the rest is irrelevant to them. We engineers tend to think 'but if this particular thing X happens in the code/stack and causes this particular problem Y, it will cause a Z% percentage problem and this will affect the user experience'. But in the end, for the overwhelming majority of the cases what ends up happening on the user side ends up being something unnoticeable to the user. Causing a lot of time to be spent for something that the users dont care about.

It feels more like we engineers use such logic of 'better code/application' to justify ourselves doing what we would like to do and build with the code than anything else that is related to the user.

> Nobody cares what your architecture looks like.

This isn't an absolute. Yes, people using your thing don't care about the architecture. But developers sure do. If your system is built in COBOL, you will have a smaller pool of developers who will have an interest in working on it.

This isn’t wrong, but I also think it’s not wrong for engineers to overcorrect a bit. It’s a balance.

Pretty much every other incentive in an organization is for product. Its really easy to build things as fast and cheap as possible until you literally can’t anymore because no one understands the code.

> 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!!!"

Leave it upto what engineers want, and they will try to build a google scale thing to put it into their resume.

Latter has a risk of attracting fanboys and detracting product engineers.

Not in my experience.

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.

I've seen this happen with Haskell for web backends for instance.

It's also been known to happen with Common Lisp and Scheme.

> 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.

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.

Staying online is one part of it, returning online after a failure is another, and there AWS will be simply incomparable to your single machine which will have burnt.

"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?

Faster disks, no control plane to fail, simpler network, etc.

This isn't bias speaking, I work on Fly.io, our VMs are less reliable than EC2 VMs. AWS's pitch is that all the extra complexity in their infrastructure benefits you. So is ours! But it is, in fact, extra complexity that will bite you in the ass if you don't build your apps the right way.

The fact that under the ec2‘s hood it’s a massively complex infrastructure as opposed to most colos.

Yea I’m left scratching my head too. Is there really a difference in reliability between an EC2 instance and colocated hardware?

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.

your personal experience has no value when discussing reliability as a whole

thank you.

Your personal experience is no match for the awesome power of AXIOMS.

US-East-1 is pretty famous for being unreliable. The other zones tend to be a lot more reliable in comparison.

There’s also a lot of selection bias: that region is the most popular and people remember hearing about problems a lot more than the people who were unaffected but didn’t say anything about it.

I’ve had plenty of instances in us-east-1 for over a decade without downtime other than the 17 minutes in 2011 where they had a network routing issue which kept the entire region running but off of the internet. I never had that with a colo - power outages & backhoes - but several came close.

For me, I’d tend to focus the question on how screwed you are if something goes down. You can save a ton of money for a bandwidth-heavy service if you use a colo so it’d really be a question of how easy it is to make it redundant (short outage) and rebuild (long outage or permanent equipment failure).

It's well known that us-east-1 (the very first) is a pet among AWS's cattle regions.

It has failure modes that none of the other regions have.

I’m aware, but my point was simply that people are prone to overstating the extent of those problems. If it was as bad as lore would have it, it’d be far less popular.

Why would you think it would be less popular? Most everyone that chooses us-east-1 chooses it because they're close to it and 1 is the first number. They don't research it before they start using it.

If people were experiencing significant downtime they’d leave us-east-1 or AWS. There’s no sign of that happening so I’d suggest that there’s a tendency to over-weight the degree to which people complaining in forums constitutes representative data.

The discussion started as us-east-1 being less reliable than other regions and has strayed far from that into guessing about human behaviour.

"Well known"

That's not sufficient evidence

> our very simple 20 machine colo center setup has been more reliable than our single region AWS setup.

What happens when there's an outage at the rack level where the 20 machines are?

Or when the whole colo is on fire? [0]

[0] https://www.datacenterdynamics.com/en/news/fire-destroys-ovh...

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.

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?

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.

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.

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.

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

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.

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.

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.

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

> 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.

(author here - oh gee, hi hn!)

Yes, those things are always important (if not critical); it's not meant as a defense of bad architecture, merely to try to make those decisions through a product/customers-first lens.

(I did try to connect quality/reliablity, perhaps unsuccessfully, later in the post, e.g. in goals: "If the system is unreliable, we won’t ship as much product ... If we don’t replace this system, more and more customers will experience a broken product.")

Maybe I was overly swayed by the rhetoric I see fairly frequently and you caveated it appropriately. I apologize if so

Or maybe I just wrote too much - I always wish I could be more concise. It's all good!

> - 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.

> 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.

> Cool, so we've established that I'm saying the tech stack matters.

Yes, and I'm telling you that all the problems you've raised are not dependent on your tech stack.

To make it clearer, it doesn't matter if you use CloudWatch Metrics or if you publish your metrics manually in an Excel file, as long as you have metrics being looked at.

"Having metrics" is not a part of your technical stack.

Similarly for speed, it doesn't matter if you use C or Python, as long as you write efficient algorithms and choose the right datastructure.

"Writing efficient algorithms and choosing the right datastructure" is not a part of your technical stack.

tbf how often did twitter and reddit break in the 2010s? how often does reddit STILL 503 under load?

if the product is really good compared to everyone else, people won't care (as much) that it's broken as long as it comes back up quickly

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)!

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.

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.

> No; customers are not paying for, nor give a shit about, these things. Sorry.

Just feels to me a bit condescending for no reason

(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.

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

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

Customers might not, but it's probably effective recruiting.

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.

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...

Keyword: after they scaled up. First they became Facebook :)

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

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".

Unless of course your product is the stack

> 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.

> 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.

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.

Amazon’s tech stack did become the product

Counterpoint: Slack

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.

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.

> 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.

Reply on news.ycombinator.com