Hacker News Reader

Comment by tmountain | Hacker News Reader

Code is a liability. Anything you choose to build requires continuous maintenance and care. Fixing things in the design stage is 100x easier than in production. Vigorously debate whether you should build something at all. If you can get something off the shelf that is well maintained and well supported, that’s usually the best option. Old and boring technology is the safe bet. Don’t get distracted by shiny objects. Continually ask yourself what your customers want, and validate those assumptions. If you’re not 100% sure, it doesn’t get built until you are.

View on HN

Yes totally agree with old & boring. Be very cautious if your developers keep suggesting new technology choices, which depending on your field is probably anything that has came out in the past 5-10 years.

Also, small teams are WAY more effective than larger teams. Software dev does not scale well at all with people in my experience. If you're constantly adding people to try and increase velocity if you've got it the wrong way round.

Obviously exceptions to this; but a good, well managed small team of 5 people can often out deliver teams many times that size.

I agree with all this. I would also add that you should avoid complexity. If you can't explain it to an engineer or you need a lot of arbitrary branching logic (the engineer will tell you), its probably not a wise decision. When engineers complain about complexity, it's not because they're lazy, it's because they know complexity is a liability and usually un-intuative in the UX. This is related to adding features as different features may interact with other features or add complexity as to what it is your product actually does.

Also something engineers should know: no one cares about your stack. Apply the minimum technology required to perform the task. No customer will go with a product just because it has a particular stack. Make it as simple as possible, but no simpler. Sometimes engineers push over-complicated technologies they are passionate about or want to learn for their own sake. You should be somewhat aware of the technology being proposed and get the input of other engineers when its something that is non-standard.

At the same time, "build vs buy" isn't always as straightforward as it sounds. You can easily end up doing a lot more work to integrate a bought component/service into your app and customize its functionality to do exactly what you want vs just building a much simpler version. I've seen companies blow many hundreds of engineer hours and thousands of lines of code on integrating with some SaaS, dealing with API changes that were out of their control, that could've just been a hundred lines of code written in an afternoon for a simpler version that handled everything they would need for years to come. You have to actually consider the tradeoffs and what you're getting for your money.

This is extremely accurate. Code is very similar to a loan for which you need to make periodic payments.

My advise is reading the comment above carefully ^^^^^

tl;dr: the best kind of software is no software at all.

This. Software are there to solve problem. Not to create more problems. If there's a problem, try figuring out a way to solve it without software first. Only use software as the last resort.

With tools like zapier and fivetran, you can build out a mini backend and data pipeline without having to think about servers or software.

And so begins an interesting philosophical conversation: is that actually less software, or is that more software pretending to be less software? I lean towards the latter, given past nightmares working with tools from the "we hide all the code behind a dank web UI" genre.

But... you do have to think about subscription fees and vendor lock-in.

I can boot a Ubuntu server for $6/mo for small sites/apps/data projects. No lock in.

You’re always locked into your infrastructure at any type of scale. I’ve worked with large VM migrations that took a year to migrate and still had issues.

That being said, I’m not going to base my entire company’s infrastructure on a small vendor that may not be around or for that matter anything that Google says is the next big thing.

For an early stage start-up I don't believe that matters. If you have success after the first couple of years, you have the luxury of time to decide what gets built to replace it. If you don't, well, at least you didn't waste time on code that wasn't the core of your business.

Case in point: Facebook, Instagram, TikTok, etc.

Reply on news.ycombinator.com