The Sad Truth About Slow Software
#1
Because we still support all our PC products, stretching back almost 40 years, I have an unusual perspective on the issue. I have
an actual IBM PC along side an XT. The AT class machines with 286 processors have all long since perished, but there are 386
and 486 computers in daily use nearby running operating systems from DOS through Win ME. Early DOS operating systems fit on
a 180kB floppy disk. That is a rounding error, these days, for drive capacity, but a kernel of truth is buried there, easy to miss.
Those disk drives are still working. Meanwhile, small piles of higher capacity drives have accumulated and been dispensed with,
many times over.

I've noticed something else about the sweep of computers from different eras. They all boot in about the length of time, and load
application software in about the same amount of time. That is fairly remarkable, considering that the processor clock rates range
from 4.77 MHz to over 80 MHz. A fast 486 processor should be able to run circles around an early 8088 processor, no? You can
argue that the newer computers are much more capable, that they have high resolution color monitors instead of the old green
screens. Well yes, if you are photo editing, there is no comparison. But if you are word processing, or entering numbers in a
spreadsheet, or, for data acquisition, perhaps monitoring an industrial oven, all the computers perform the same tasks with near
equal utility and in about the same amount of time. How is that possible?

Is it a sort of Peter Principle for computers - All computers rise to their level of incompetence? Clearly it has to be the software,
but how?

Any tech company employing programmers has to manage programmer's time efficiently in order to survive. Salary costs quickly
dwarf the cost of the computers used for software development. So, those programmers are almost always coding on screaming-
fast newer computers. The rest of us, not so much. So when you test software on other computers around the company, computers
which might have been discarded as too slow by the programmers, you can expect sluggish behavior. If you plunk a slow computer
down on the programmer's desk and demand speed improvements, you are apt to quickly discover how deeply buried all that
sluggishness has become. It is not a matter of a little code reshuffling and prioritizing, the slowness is close to the bone. The only
way I know to write fast software is to develop on slow machines. Good luck finding programmers willing to help you with that.

It just doesn't pay to employ a programmer to speed up slow software, and that is the sad truth.

Tom Lawson
November 2020
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)