5 ms·

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.

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.

ryukoposting 3y ago
tl;dr: the best kind of software is no software at all.
- nonethewiser 3y ago
  Case in point: Facebook, Instagram, TikTok, etc.
- morkalork 3y ago
  With tools like zapier and fivetran, you can build out a mini backend and data pipeline without having to think about servers or software.
  - lifechoseme123 3y ago
    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.
    - morkalork 3y ago
      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.
    - scarface_74 3y ago
      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.
  - ryukoposting 3y ago
    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.
- jan_Sate 3y ago
  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.
bko 3y ago
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.
martinald 3y ago
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.
crop_rotation 3y ago
This is extremely accurate. Code is very similar to a loan for which you need to make periodic payments.
ghomem 3y ago
My advise is reading the comment above carefully ^^^^^
thraxil 3y ago
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.

ryukoposting 3y ago

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

nonethewiser 3y ago
Case in point: Facebook, Instagram, TikTok, etc.
morkalork 3y ago
With tools like zapier and fivetran, you can build out a mini backend and data pipeline without having to think about servers or software.
- lifechoseme123 3y ago
  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.
  - morkalork 3y ago
    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.
  - scarface_74 3y ago
    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.
- ryukoposting 3y ago
  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.
jan_Sate 3y ago
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.

bko 3y ago

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.

martinald 3y ago

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.

crop_rotation 3y ago

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

ghomem 3y ago

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

thraxil 3y ago

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.