Re:Lessons for software developers from 1970s mainframe prog...
by mahkoh on Saturday January 13, 2018 @07:14PM
(#16142153)
This is actually a problem that will fix itself in time. Soon the customer won't be able to run your quickly shipped product because his computer is not powerful enough to run more than 5 electron apps. If we take a browser, a text editor, and chat software as a given, only two more electron apps will be able to compete for the customer's remaining resources.
Re:Lessons for software developers from 1970s mainframe prog...
by yodon on Saturday January 13, 2018 @07:19PM
(#16142176)
At which point the customer blames Microsoft for making Windows too slow. The chain of events between your app and their computer’s speed is sufficiently nebulous in the mind of your customers that it’s impact on your success will objectively be zero. I get that you hate Electron apps, and I understand why, but the reality is Slack and VS Code and others have been wildly successful. You might not use them, but millions of others do, and they were fast and cheap to develop.
Re:Lessons for software developers from 1970s mainframe prog...
by bandrami on Saturday January 13, 2018 @06:56PM
(#16142091)
> The business cares that it can get to market quickly and profitably at minimal cost.
And then the successful business, in contrast, actually looks at total cost of ownership.
Re:Lessons for software developers from 1970s mainframe prog...
by yodon on Saturday January 13, 2018 @07:00PM
(#16142097)
We are completely on the same page there, though I would say “care about the risk adjusted total cost of ownership.” Early on, the business doesnt know if the product will succeed so the risk is high and any developer time/dollars invested are disproportionately high risk adjusted TCO. Once the product is successful, the operational costs dominate and the risk factor of time/dollars spent on dev time to optimize the code falls, justifying time spent to improve the efficiency across many measures, but those things don’t kick in until there is some measure of success in the market. Until then, risk adjusted TCO for dev time is very very high and needs to be aggesssively minimized to achieve that minimum risk adjusted total cost of ownership.
Re:Lessons for software developers from 1970s mainframe prog...
by 549362-30499 on Saturday January 13, 2018 @07:17PM
(#16142165)
The point is that cloud computing costs are small compared to labor costs, so it's a waste of time to make a 0.005% cost optimization that takes a week of work.
I would also love to see some examples of a 2G (!) library that people are casually importing. Where have you had this problem?
Re:Lessons for software developers from 1970s mainframe prog...
by bandrami on Saturday January 13, 2018 @09:55PM
(#16142579)
Labor costs are capital expenses; computing cost is an ongoing operational expense.
Re:Lessons for software developers from 1970s mainframe prog...
by dgsb on Sunday January 14, 2018 @05:17AM
(#16143596)
In the end, it depends on return on investment. If it is something which will be deployed on running for years, it may worth the effort.
Re:Lessons for software developers from 1970s mainframe prog...
by JustSomeNobody on Sunday January 14, 2018 @07:18AM
(#16143954)
It's not about developer time. Get over yourselves. It is about how long the user has to wait for a page to load or a compute to finish.
Re:Lessons for software developers from 1970s mainframe prog...
by bandrami on Sunday January 14, 2018 @08:28AM
(#16144159)
And for that matter, it can take as long to select the library and learn the API as it would have to write the function to begin with.
Re:Lessons for software developers from 1970s mainframe prog...
by klibertp on Sunday January 14, 2018 @11:36AM
(#16144908)
You say:
> said no customer, ever
and then:
> witness that we all use compilers
Well, strictly speaking, developers are also customers for programming tools' company, and there the tidiness of the code is important. I'm sure there are many other domains where writing your software well is actually encouraged by economic factors :)
The craftsman cares they can accomplish the task without needing a large library. The business cares that it can get to market quickly and profitably at minimal cost. “I prefer your competitor because their code was lovingly hand crafted instead of being shipped quickly with the features I need” said no customer, ever (witness that we all use compilers rather than hand-coding the machine code in an assembler... all the same arguments were made against compiled code back in the day, and compiled code was the right answer, then and now).