I really like the point about considering cloud computation costs. It would be great if individual developers could get feedback like, "This patch caused X% CPU cost per request, resulting in Y% monthly cost increase to keep projected usage below alert trigger levels." I also like the note about the headless abstraction, although I think it could gain some strength by talking about AWS Lambda or the actor model. But,…
Lessons for software developers from 1970s mainframe programming
11–20 of 89 posts
Re: Lessons for software developers from 1970s mainframe programming
#12Earlier quoted context omitted.
Yes, because the primary cost to the company is the cost of developer time, not the download bandwidth cost or the power cost for increased utilization level of the user’s CPU. 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 inste…
> 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 programming
#13Unfortunately, the "best practice" of today says it's better to import a 2 Gb library than write a function, given the choice.
Yes, because the primary cost to the company is the cost of developer time, not the download bandwidth cost or the power cost for increased utilization level of the user’s CPU. 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 inste…
Re: Lessons for software developers from 1970s mainframe programming
#14Earlier quoted context omitted.
software development != web software development. Processing efficiency is still extremely important in the embedded world. Don't think that the embedded market is small, practically every product you buy has s/w in it. When you make for example a million units of a product, every single byte and every cycle counts as there is a large multiplier to take account of. Efficiency counts, just not in the web world.
Well said, but embedded developers already know this and behave as if their compute resources are scarce. I read the author as speaking to developers generally, which I think was his intent.
Re: Lessons for software developers from 1970s mainframe programming
#15Earlier quoted context omitted.
Yes, because the primary cost to the company is the cost of developer time, not the download bandwidth cost or the power cost for increased utilization level of the user’s CPU. 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 inste…
> 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.
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 programming
#16Unlike the stand-alone, isolated mainframe era, our applications today are interconnected. In an academic environment, perhaps the author didn't experience intersystem dependencies. In production environments, however, there was arguably more interdependency with (and, therefore, risk to) other systems and users. Take a manufacturing environment. Shop orders take in inventory information, labor detail, assembly progr…
The web has become a very frequent path for machine-to-machine communications through APIs, besides other, more direct pathways for internet traffic on ports other than 80/443.
Re: Lessons for software developers from 1970s mainframe programming
#17Interesting article but the author seems trapped in an antiquated “compute time is more expensive than developer time” mindset. For most startups today the EC2 budget is negligible compared to the dev team budget. If you’re successful enough that the compute cost matters that’s a good thing and you can deal with it then. Optimizing for problems you don’t yet have just keeps you from launching and getting successful e…
Re: Lessons for software developers from 1970s mainframe programming
#18Earlier quoted context omitted.
Yes, because the primary cost to the company is the cost of developer time, not the download bandwidth cost or the power cost for increased utilization level of the user’s CPU. 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 inste…
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 programming
#19Unfortunately, the "best practice" of today says it's better to import a 2 Gb library than write a function, given the choice.
Re: Lessons for software developers from 1970s mainframe programming
#20Interesting article but the author seems trapped in an antiquated “compute time is more expensive than developer time” mindset. For most startups today the EC2 budget is negligible compared to the dev team budget. If you’re successful enough that the compute cost matters that’s a good thing and you can deal with it then. Optimizing for problems you don’t yet have just keeps you from launching and getting successful e…
software development != web software development. Processing efficiency is still extremely important in the embedded world. Don't think that the embedded market is small, practically every product you buy has s/w in it. When you make for example a million units of a product, every single byte and every cycle counts as there is a large multiplier to take account of. Efficiency counts, just not in the web world.