3 ms·

> Why should you isolate an engineer from that as though it doesn't matter? Because it's not their job and therefore they don't have the information necessary

> Why should you isolate an engineer from that as though it doesn't matter? Because it's not their job and therefore they don't have the information necessary to know what is or isn't expensive. Their job is to come up with the best design using common sense when it comes to cost. Cost of a part isn't the only thing that matters either. Ok, we can save 1 cent if we swap this part out. But now we have to purchase lot sizes that are 10x bigger. How does that impact production? How does that affect operational budgets? Etc. The engineers engineer and the bean counters count beans. They meet and find a happy place. Why would you even want that extra workload? The fact that you think it's so easy just goes to show why actual accountants do the accounting, managers do the managing, procurement does the procuring, and operations does the operating. "I know calculus, accounting is easy!" Sure, if you throw out all of the variables other than unit cost.

Panzer04 2y ago
This seems insane to me. It's not that hard to have a ballpark awareness of how much things cost. You need accountants etc because you need to ensure that all of the little things are done, not so that everyone else in the business can be unaware of the business case for their product. Yes, you shouldn't care about lot sizes and cost breaks (unless they are significant deciding factors), but knowing that one operation is going to cost 2x another, largely equivalent operation is relvant/important.
- pclmulqdq 2y ago
  Exactly, there is no "engineering" separate from the beans. Anyone can make a bridge that stands. It takes an engineer to make one that barely stands. The same largely goes for computer systems.
  - kijin 2y ago
    When the economy is booming and there's a lot of money sloshing around, developers can get away with shrugging and saying "not my problem" to things like cloud costs and energy efficiency. Those same developers don't get to complain on the rainy day, when someone who knows how to save the company millions of dollars a year gets a better deal.
  - Retric 2y ago
    Engineer’s don’t build bridges that barely stand up, they have a huge margin at completion. Instead they build bridges based on some agreed upon lifespan.
    - pclmulqdq 2y ago
      They do make the cheapest thing counting that margin. Immediately past that margin of safety, your bridge will fall down. In other words, given an expected load of 10 tons and a 50 year lifetime (as you mentioned), an engineer will try to design the cheapest possible bridge that holds 50 tons (5x load) and will last 70 years.
      - Retric 2y ago
        Being able to handle 50 tons at year 70 may be well over 200 tons at year 1, which is a hell of a lot more than a simple 5x margin.
        pclmulqdq 2y ago
        Sure. Pick a specified load at a specified time and the engineer's job is to build the cheapest possible bridge at that load and time. Raising the safety factor doesn't change the objective function. The objective function is still "cheapest within spec." This is why bridges are not just huge chunks of titanium. Those would work very well at handling 50 tons at year 70, but would be shitty bridges because they are too expensive to build.
        Retric 2y ago
        I agree that cost is a factor, but cheap is really only one of many factors being optimized. The actual cheapest design is often some organic looking design that comes out of software optimizer, but you lower risk by using proven designs.
        pclmulqdq 2y ago
- bongodongobob 2y ago
  I'm not saying you should be completely ignorant of price, I'm saying use the standard parts and practices first, then worry about costs in revisions after you've built something. Premature optimization and so on. Maybe you can save money on a different powder coat color so you don't have to worry about skimping on parts or power conditioning or something like that. The project is usually bigger than the engineers little corner.
  - Panzer04 2y ago
    That's fair. Get something working > Doing it right/perfectly the first time, most of the time. That being said, you should be able to have enough awareness to avoid anything particularly egregious - eg. avoid things that you would never want in a final product anyway in the first place. I guess we probably agree on that when you say standard parts etc.
pclmulqdq 2y ago
> Because it's not their job and therefore they don't have the information necessary to know what is or isn't expensive. It is your job, when you make something, to understand how it works. How much it costs to operate is an integral part of how it works. > Ok, we can save 1 cent if we swap this part out. But now we have to purchase lot sizes that are 10x bigger. How does that impact production? How does that affect operational budgets? Etc. A 10x larger lot size makes each part per unit cheaper and it simplifies production to eliminate items from your BoM. Understanding that sort of thing in an order-of-magnitude sense is also part of your job. By the way, you don't need to know this stuff precisely to make good decisions. You need to know it roughly. You still need to know it, though.
- kube-system 2y ago
  But business process cost is often not part of a software engineers job, or at least, many do not see it as one. I have often seen software engineers spend days or weeks building something that can be purchased off the shelf for less than a couple hundred dollars.
dotancohen 2y ago
> The engineers engineer and the bean counters count beans. They meet and find a happy place. I'd say that the engineers never initiate contact with the bean counters, and the bean counters very very rarely initiate contact with the engineers.

Panzer04 2y ago

This seems insane to me. It's not that hard to have a ballpark awareness of how much things cost. You need accountants etc because you need to ensure that all of the little things are done, not so that everyone else in the business can be unaware of the business case for their product. Yes, you shouldn't care about lot sizes and cost breaks (unless they are significant deciding factors), but knowing that one operation is going to cost 2x another, largely equivalent operation is relvant/important.

pclmulqdq 2y ago
Exactly, there is no "engineering" separate from the beans. Anyone can make a bridge that stands. It takes an engineer to make one that barely stands. The same largely goes for computer systems.
- kijin 2y ago
  When the economy is booming and there's a lot of money sloshing around, developers can get away with shrugging and saying "not my problem" to things like cloud costs and energy efficiency. Those same developers don't get to complain on the rainy day, when someone who knows how to save the company millions of dollars a year gets a better deal.
- Retric 2y ago
  Engineer’s don’t build bridges that barely stand up, they have a huge margin at completion. Instead they build bridges based on some agreed upon lifespan.
  - pclmulqdq 2y ago
    They do make the cheapest thing counting that margin. Immediately past that margin of safety, your bridge will fall down. In other words, given an expected load of 10 tons and a 50 year lifetime (as you mentioned), an engineer will try to design the cheapest possible bridge that holds 50 tons (5x load) and will last 70 years.
    - Retric 2y ago
      Being able to handle 50 tons at year 70 may be well over 200 tons at year 1, which is a hell of a lot more than a simple 5x margin.
      - pclmulqdq 2y ago
        Sure. Pick a specified load at a specified time and the engineer's job is to build the cheapest possible bridge at that load and time. Raising the safety factor doesn't change the objective function. The objective function is still "cheapest within spec." This is why bridges are not just huge chunks of titanium. Those would work very well at handling 50 tons at year 70, but would be shitty bridges because they are too expensive to build.
        Retric 2y ago
        I agree that cost is a factor, but cheap is really only one of many factors being optimized. The actual cheapest design is often some organic looking design that comes out of software optimizer, but you lower risk by using proven designs.
        pclmulqdq 2y ago
bongodongobob 2y ago
I'm not saying you should be completely ignorant of price, I'm saying use the standard parts and practices first, then worry about costs in revisions after you've built something. Premature optimization and so on. Maybe you can save money on a different powder coat color so you don't have to worry about skimping on parts or power conditioning or something like that. The project is usually bigger than the engineers little corner.
- Panzer04 2y ago
  That's fair. Get something working > Doing it right/perfectly the first time, most of the time. That being said, you should be able to have enough awareness to avoid anything particularly egregious - eg. avoid things that you would never want in a final product anyway in the first place. I guess we probably agree on that when you say standard parts etc.

pclmulqdq 2y ago

> Because it's not their job and therefore they don't have the information necessary to know what is or isn't expensive. It is your job, when you make something, to understand how it works. How much it costs to operate is an integral part of how it works. > Ok, we can save 1 cent if we swap this part out. But now we have to purchase lot sizes that are 10x bigger. How does that impact production? How does that affect operational budgets? Etc. A 10x larger lot size makes each part per unit cheaper and it simplifies production to eliminate items from your BoM. Understanding that sort of thing in an order-of-magnitude sense is also part of your job. By the way, you don't need to know this stuff precisely to make good decisions. You need to know it roughly. You still need to know it, though.

kube-system 2y ago
But business process cost is often not part of a software engineers job, or at least, many do not see it as one. I have often seen software engineers spend days or weeks building something that can be purchased off the shelf for less than a couple hundred dollars.

dotancohen 2y ago

> The engineers engineer and the bean counters count beans. They meet and find a happy place. I'd say that the engineers never initiate contact with the bean counters, and the bean counters very very rarely initiate contact with the engineers.