What Today's Coders Don't Know and Why It Matters

jfruhlinger writes "Today's programmers have much more advanced languages and more forgiving hardware to play with — but it seems many have forgotten some of the lessons their predecessors picked up in a more resource-constrained era. Newer programmers are less adept at identifying hardware constraints and errors, developing thorough specifications before coding, and low-level skills like programming in assembly language. You never know when a seemingly obsolete skill will come in handy. For instance, Web developers who cut their teeth in the days of 14.4 Kbps modems have a leg up in writing apps for laggy wireless networks."

Comments

Re:This...

[JamesP]

the worse code, yes

But that runs fast on old/not so fast hardware

Example http://en.wikipedia.org/wiki/Fast_inverse_square_root

Re:The problem is

[wrook]

There aren't good engineering practices in software. This is why I abjectly refuse to call myself an engineer (that and I'm *not* an engineer). Can you tell me with a known degree of certainty the probability that a software component will fail? What procedures would you put into place to give you that number (keeping in mind the halting problem)? What procedures would you put into place to mitigate those failures? Because I'm drawing a big gigantic blank here.

Look, I'm all for using "Software Engineering" practices. Personally, in my career I have championed TDD, peer review, acceptance tests written in advance by someone other than the programmers, etc, etc, etc. But this isn't engineering. The best I can tell anyone is, "Hey, it doesn't break on *my* machine. Yeah, I think the probability of it breaking on your machine is 'low'. No, I wouldn't like to specify a number, thank you very much." Why do you think software never comes with a warrantee?

I often wonder what we could do to actually make this an engineering discipline. For one thing, I think we really need to invest in developing stochastic testing techniques. We need to be able to characterise all the inputs a program can take and to test them automatically in a variety of different ways. But this is the stuff of research. There are some things we can do now, but it's all fairly naiscent technology. Maybe in 20 years... :-P

Yesterday's coders aren't necessarily relevant

[Just Some Guy]

Some old-school developers prematurely optimize for things we no longer need to optimize for (and shouldn't). From an older post of mine:

A recent experience with an ex-coworker illustrated this pretty well for me:

Said fellow, call him "Joe", had about 30 years of COBOL experience. We're a Python shop but hired him based on his general coding abilities. The problem was that he wrote COBOL in every language he used, and the results were disastrous. He was used to optimizing for tiny RAM machines or tight resource allocations and did things like querying the database with a rather complex join for each record out of quite a few million. I stepped in to look at his code because it took about 4 hours to run and was slamming the database most of the time. I re-wrote part of it with a bit of caching and got the run-time down to 8 seconds. (Choose to believe me or not, but I'd testify to those numbers in court.) I gave it back to him, he made some modifications, and tried it again - 3 hours this time. I asked him what on Earth he'd done to re-break the program, and he'd pretty much stripped out my caching. Why? Because it used almost half a gig of RAM! on his desktop and he thought that was abhorrent.

Never mind that it was going to be run on a server with 8GB of RAM, and that I'd much rather use .5GB for 8 seconds than 1MB for 3 hours of intense activity.

So Joe isn't every COBOL programmer, but you and I both know that he's a lot of them. But back to the direct point, how much of that 250GLOC was written with the assumption that it'd be running on 512KB machines or with glacial hard drives or where making the executable as tiny as possible was an extreme priority? Doing things like storing cache data in hash tables would've been obscenely expensive back in the day, so those old algorithms were designed to be hyper-efficient and dog slow. Whether you think that constitutes "working well" is up to you.

He was optimizing for resources that were no longer constrained, and consequently pessimizing for the resources we actually cared about. RAM? Dirt cheap, at least for the dataset sizes involved in that project. Much more expensive was all the extra disk and CPU load he was creating on the company-wide database server (which is sufficiently powerful to serve the entire company when it's not being deliberately assaulted).

I'm not "anything goes" by any means, and I'm the guy responsible for making sure that lots of processes can peacefully coexist on an efficiently small number of servers. But for all intents and purposes, most of our apps have unlimited resources available to them. If they want to use 100% of a CPU core for 5 minutes or 2GB of RAM for half an hour a day, so be it. I'd much rather run simple, testable, maintainable code that happens to use a lot of server power than lovingly hand-mangled code that no one but the original programmer can understand and which interacts with the rest of the network in entertainingly unpredictable ways.

Re:tl;dr

[jellomizer]

Having developed on old platforms and new ones and back to old one. You actually get much better quality out of the new stuff. We look back at the old software with pride on how well it runs, forgetting the decades of errors and problems it had in the past, and the years of effort it took to get them run at that level.

The old stuff seems to run faster but not really. Old word perfect, no realtime spell check, no fonts, bold and italics were the big features, along with multi-column and margins. The display was 80x25 and still the app crashed and you lost all your work. And took minutes to load off your floppy.

Can new developers write tighter code. Sure they are not stupid. But how much can you loose from doing it? Getting in too late in the market? Loss of multi-platform support? Hard to maintain? Vulnerable to hacking?

I just heard a report that the high frequency trading systems are easy to hack into because they have been developed for all speed... Leaving room for hacking in. As anyone has done coding knows it takes 10% to get the program to do what it needs to do and the rest to make sure humans don't cause it to do something else.