Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree whole-heartedly. Every place I've worked, I get the side eye whenever I talk about how the patterns being used are dangerous, and will only get us so far before we have to re-write everything in a panic to handle a new use-case for a customer.

It's something that took me a long time in my career to understand: businesses care about profits, and since we are all salaried, they don't care if we have to work ridiculous hours patching a buggy, shit system. They just want to get a polished turd into the hands of customers ASAP.

On one hand, I get it. Why build the worlds greatest system, and design it so well that it will never fail, and it will scale effortlessly, and it will be easy to add new features indefinitely? That will likely take 3 or 4 times longer to bring to market, and if the value proposition doesn't add up, it's not going to happen. So I guess we have to leave the good architecture to the firms where it is critical: NASA, medical devices, avionics, etc.




There are a few things wrong here.

Businesses do often (usually) care how many hours you spend patching "buggy, shit systems". Because programmers are expensive. Obviously.

They do not care about meeting arbitrary, irrelevant standards, like extensibility for features they will never need. Because that's expensive, obviously.

Meeting arbitrary unneeded goals even takes a toll on actually relevant goals, like being able to adapt software quickly. I don't understand how you think this would not be a worthwhile goal.

> design it so well that it will never fail

Too much black and white thinking. Most problem domains don't need "will never fail", but are ok with "fails only seldom". And meeting "will never fail" is extremely expensive, obviously.

> So I guess we have to leave the good architecture to the firms where it is critical: NASA, medical devices, avionics, etc.

A good architecture is one that helps towards actual goals. And that's not extreme extensibility or extreme correctness, in most cases.

For a concrete example, think about a game engine. It will not meet most arbitrary goals you could make up (it will fail, sometimes, and it can't make your coffee). But still I hope you can agree that there are many really well architected game engines.


Most businesses don't (and shouldn't) care about software for software's sake. But they do care about their software delivering value, and product and sales teams are very aware of the value that good software provides - and the costs of bad software - since they're the ones who have to drop feature ideas or turn away clients.

Ironically, I've found that selling good software engineering practices to engineers can be much harder than selling it to other teams. Good software also doesn't take longer to get to market - I think on anything but the shortest of terms, building high quality software pays off immensely. You're saying two contradictory things here: that we can "design it so well that it will never fail, and it will scale effortlessly, and it will be easy to add new features indefinitely" but also that it takes 3-4 times longer to bring to market. If I can effortlessly build features, why do they take longer to get to market? I think a lot of software engineers believe that there is a trade-off between quality and efficiency, but I think that's the opposite of the truth: if you trade off quality, you are trading off long-term efficiency as well. Likewise an investment in quality is an investment in efficiency.


There's lot of software written in non-tech firms to support the company's core business. The whole finance industry is like that for example. In my experience, they care a lot about quality and architecture (for example, in some of the projects I've seen there's more devops or automatic testers than developers).




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: