6 ms·

Its best to understand early that an Engineer deals in two commodities: money and time. Their job is not to create ivory-tower ideal solutions. The whole proble

Its best to understand early that an Engineer deals in two commodities: money and time. Their job is not to create ivory-tower ideal solutions. The whole problem, the reason Engineers exists, is to manage technology such that the constraints of money and time can be met.

dachryn 5y ago
yeah but the problem is: which budget are you optimizing? That of the company of course. You offload a lot of bullcrap onto the end user. Like the author said, wasting electricity and battery life and thousands of devices just because you cant be bothered to generate html on the server to serve simple text is a common thing for news sites. This is wasting the time as well of the end user, because its slower to load, and lower performant on the device itself
- masklinn 5y ago
  > yeah but the problem is: which budget are you optimizing? That of the company of course. The budget of the company is predicated upon what the user will be willing to pay for the service. You’re wasting electricity and battery life of thousands of devices of users who don’t care or want to “vote with their feet”. Now obviously users are also constrained by what is made available to them, but time and again the shiny and early to market wins out even if it’s a literal trash fire…
argiopetech 5y ago
The saying about optimization goes, "Time, Cost, Quality: Choose two." You've chosen the two that most profit-minded entities choose, but they are not the only choices. Optimizing for quality and time can be a winning solution, particularly if you can achieve novelty as well. Countless corporations and founders have had success with the strategy (Apple under Jobs comes to mind.) Optimizing for quality and cost is also viable: Deming preached it, and e.g., Japanese car manufacturers have showed it to be a highly successful strategy.
- JoeAltmaier 5y ago
  Notice it's not the engineer doing the choosing in that optimization. You're asking the client to choose. Then you execute. You can give any number of examples where time has a loose constraint.
pydry 5y ago
You know, I hear this argument a lot for e.g. why Slack is a dog slow electron beast. The thing is, slack has not been short of time OR money for at least the last 5 years. They could have easily built leaner, faster native apps and customers would have appreciated it. This "ivory tower" stuff smacks of just world/just market fallacy. I suspect there are deeper issues here. For example, vendor lock-in inhibiting competition paired with the "electron app team" being a powerful fiefdom within the company. IME the concealed undercurrent of politics tends to provide a better explanation for many hard to understand decisions at large companies than unexpected technical prudence. Why does Uber's app require 150 developers? Why is Facebook's app such a beast? Why did they create a whole new "lite" app rather than slimming it? Why does Google have 13 messengers? Reaching for a calm, rational engineering decision to explain each case is tempting, but wrong.
- jack_pp 5y ago
  So once you have an app up and running, with millions of satisfied users you would hire another team of more expensive developers to build a native app.. for each platform? so make that 2 more teams or rather 4 more teams? (iOS, Mac, Android, Windows)
  - pydry 5y ago
    They're a $24 billion company. Hiring 4 small teams probably shouldnt be too much for them.
    - tanseydavid 5y ago
      ...and one PM to manage all 4 teams and ensure that there is no feature-drift between the various OS-target versions. </sarc> I am really just trying to emphasize that there are tradeoffs lurking everywhere and they are often hidden by assumptions.
      - Siira 5y ago
        Telegram already does this with a rather small team. Hell, there are even third-party Telegram clients that, while a bit behind the features, eventually catch up with every single one.
beowulfey 5y ago
See, this is interesting to me, because I come from a different engineering background and was taught that the constraints were safety first, then cost. Time to build was a part but not as important as those other two. Obviously safety is a bit less important in the software world, but hearing time be a key part of an engineer’s focus makes me uneasy for some reason, even though it makes a lot of sense from a business perspective.

dachryn 5y ago

yeah but the problem is: which budget are you optimizing? That of the company of course. You offload a lot of bullcrap onto the end user. Like the author said, wasting electricity and battery life and thousands of devices just because you cant be bothered to generate html on the server to serve simple text is a common thing for news sites. This is wasting the time as well of the end user, because its slower to load, and lower performant on the device itself

masklinn 5y ago
> yeah but the problem is: which budget are you optimizing? That of the company of course. The budget of the company is predicated upon what the user will be willing to pay for the service. You’re wasting electricity and battery life of thousands of devices of users who don’t care or want to “vote with their feet”. Now obviously users are also constrained by what is made available to them, but time and again the shiny and early to market wins out even if it’s a literal trash fire…

argiopetech 5y ago

The saying about optimization goes, "Time, Cost, Quality: Choose two." You've chosen the two that most profit-minded entities choose, but they are not the only choices. Optimizing for quality and time can be a winning solution, particularly if you can achieve novelty as well. Countless corporations and founders have had success with the strategy (Apple under Jobs comes to mind.) Optimizing for quality and cost is also viable: Deming preached it, and e.g., Japanese car manufacturers have showed it to be a highly successful strategy.

JoeAltmaier 5y ago
Notice it's not the engineer doing the choosing in that optimization. You're asking the client to choose. Then you execute. You can give any number of examples where time has a loose constraint.

pydry 5y ago

You know, I hear this argument a lot for e.g. why Slack is a dog slow electron beast. The thing is, slack has not been short of time OR money for at least the last 5 years. They could have easily built leaner, faster native apps and customers would have appreciated it. This "ivory tower" stuff smacks of just world/just market fallacy. I suspect there are deeper issues here. For example, vendor lock-in inhibiting competition paired with the "electron app team" being a powerful fiefdom within the company. IME the concealed undercurrent of politics tends to provide a better explanation for many hard to understand decisions at large companies than unexpected technical prudence. Why does Uber's app require 150 developers? Why is Facebook's app such a beast? Why did they create a whole new "lite" app rather than slimming it? Why does Google have 13 messengers? Reaching for a calm, rational engineering decision to explain each case is tempting, but wrong.

jack_pp 5y ago
So once you have an app up and running, with millions of satisfied users you would hire another team of more expensive developers to build a native app.. for each platform? so make that 2 more teams or rather 4 more teams? (iOS, Mac, Android, Windows)
- pydry 5y ago
  They're a $24 billion company. Hiring 4 small teams probably shouldnt be too much for them.
  - tanseydavid 5y ago
    ...and one PM to manage all 4 teams and ensure that there is no feature-drift between the various OS-target versions. </sarc> I am really just trying to emphasize that there are tradeoffs lurking everywhere and they are often hidden by assumptions.
    - Siira 5y ago
      Telegram already does this with a rather small team. Hell, there are even third-party Telegram clients that, while a bit behind the features, eventually catch up with every single one.

beowulfey 5y ago

See, this is interesting to me, because I come from a different engineering background and was taught that the constraints were safety first, then cost. Time to build was a part but not as important as those other two. Obviously safety is a bit less important in the software world, but hearing time be a key part of an engineer’s focus makes me uneasy for some reason, even though it makes a lot of sense from a business perspective.