Live data from Hacker News

Lessons for software developers from 1970s mainframe programming

hpe.com

11–20 of 89 posts

Re: Lessons for software developers from 1970s mainframe programming

#11

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,…

One thing I hate about the modern disregard for resource consumption is that I can't tell whether a given app or program is merely sloppily inefficient, or if it's ma!ware-laden. (Too often, it's probably both.)

Re: Lessons for software developers from 1970s mainframe programming

#12
post #5

Earlier 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.

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 programming

#13
post #5
post #2

Unfortunately, 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…

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

#14
post #9

Earlier 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.

If web developers would be so kind as to consider my compute resources as scarce that would tremendously please me. This sort of thinking is important, you just need to be selective about when and where you apply it.

Re: Lessons for software developers from 1970s mainframe programming

#15
post #5

Earlier 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.

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 programming

#16
post #7

Unlike 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…

> I'd daresay that most interconnection with external systems in the modern mobile environment is primarily used for social media, tracking and other privacy suckage. (Ghostery output can be quite surprising, for example.)

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

#17
post #3

Interesting 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…

In a non-startup world (established business), imagine if you went to the boss and said "If you give me 3 or 4 weeks for optimization I believe I can cut our Azure bill by 15%, year over year". You'd get his attention pretty quickly.

Re: Lessons for software developers from 1970s mainframe programming

#18
post #13
post #5

Earlier 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.

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 programming

#19
post #2

Unfortunately, the "best practice" of today says it's better to import a 2 Gb library than write a function, given the choice.

When that library is, e.g., numpy: absolutely. God help you if you think you're better at linear algebra than BLAS or LAPACK is.

Re: Lessons for software developers from 1970s mainframe programming

#20
post #3

Interesting 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.

The parent comment (which I didn’t write) seems to be getting up voted and down voted repeatedly, bouncing in and out of gray. Could one of the downvoters explain your objection? (Genuinely curious, looking to learn)
Post reply on HN