Lessons for software developers from 1970s mainframe programming

#1

Post by rbanffy » Sat, Jan 13, 2018, 10:14 PM UTC

Lessons for software developers from 1970s mainframe programming
hpe.com

Re: Lessons for software developers from 1970s mainframe programming

#2

Post by bandrami » Sat, Jan 13, 2018, 11:27 PM UTC

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

#3

Post by yodon » Sat, Jan 13, 2018, 11:42 PM UTC

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 enough to actually care about your compute costs.

Re: Lessons for software developers from 1970s mainframe programming

#4

Post by 549362-30499 » Sat, Jan 13, 2018, 11:49 PM UTC

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, I think the dedication to writing perfect code without executing it is misguided. It's 2018 - we have interactive debuggers, excellent profiling tools, and unit tests. Most developers have a computer with 4+ cores and 8G+ of memory. It would be foolish not to take advantage of that.

Re: Lessons for software developers from 1970s mainframe programming

#5

Post by yodon » Sat, Jan 13, 2018, 11:50 PM UTC

bandrami wrote: 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 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).

Re: Lessons for software developers from 1970s mainframe programming

#6

Post by TickleSteve » Sat, Jan 13, 2018, 11:51 PM UTC

yodon wrote: 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.

Re: Lessons for software developers from 1970s mainframe programming

#7

Post by DrScump » Sat, Jan 13, 2018, 11:53 PM UTC

  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 progress, facilities and supplies usage, etc., any or all of which can involve independent systems. In turn, each production step can create information that needs to go back to each system.

Any error or change in those inputs and outputs could force a rerun of all systems downstream of the first error. This is especially noteworthy to the guy/gal being called in at 3AM to unravel such hairballs.

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

Re: Lessons for software developers from 1970s mainframe programming

#8

Post by Yetanfou » Sat, Jan 13, 2018, 11:53 PM UTC

yodon wrote: 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…

...but giving the design a bit more thought to end up with something which either is more performant or can be easily optimised at a later stage does pay off in the long term.

Re: Lessons for software developers from 1970s mainframe programming

#9

Post by yodon » Sat, Jan 13, 2018, 11:54 PM UTC

TickleSteve wrote: post #6

yodon wrote: 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.

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

#10

Post by bandrami » Sat, Jan 13, 2018, 11:56 PM UTC

yodon wrote: post #5

bandrami wrote: 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…

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