While chillin’ with a fresh Caucasian, the Dude read a blog that was interesting. Its premise was that developers should always have the fastest, best hardware to minimize down time. Waiting 12 seconds to compile a module was too long, and encouraged the developer’s attention to stray to Reddit, or some other time sink, and then they would lose a half hour. To minimize this tendency, developers should have wicked awesome machines to reduce this tendency.
While the Dude can sympathize with the sentiment, he thinks it is bad advice. We make scientific instruments. They have controllers that are essentially PC’s. They run Windows, and they run our software that then runs the instrument. But, these “controllers” are never leading edge computers. They are what you can source from Dell’s “stable” product line, meaning that if you pick a configuration, Dell won’t fuck with it for 18 months or so, and you can count on it “just working”. We choose those computers to be fast enough, but not too expensive (because COGS is important). Beyond that, we have been selling instruments for 15+ years. In the current generation, launched in 2004, there are a lot of customers with older systems. Think Pentium IV’s, Windows XP, and 1G RAM (if that).
Truisms in the instrument business are that people expect support for a LONG time. These are expensive systems, and they expect, scratch that, demand 5 or more years of life. People also expect there to be perpetual free software upgrades. (A topic for a different post is how this came to be, and how futile it is to try and change it) But what happens when your developers are using a 12 core Xeon system with 24 G ram, and a SSD raid array on their desktop?
All incentive to write efficient code is eliminated – Why clean up a messy class when you can just keep adding to it? Why worry about efficient data handling when you have enough memory to run 50 VM’s?
Cleaning the cruft is never in the plan – Who cares if your executable becomes 80 or 90 megabytes? Why bother deprecating legacy? Why rewrite spaghetti legacy code when you can just wrap it and make an object class?
You poo-poo support calls about slow or unresponsive software – of course you can’t replicate the issue, you are running on a machine that is so over kill (and so expensive we would never spec it for shipment) that you do not see dialog boxes that take 10 seconds to draw, or data files that crash the system because it can’t allocate enough memory, or the UI becomes non-responsive for 30 seconds at a time, because it is trying to do real time 3D manipulation of 90 megabyte data sets.
The answer isn’t to take the fast systems away from the developers and make them suffer. But instead, you need to codify the practice of testing on two or three generations old PC’s. Also, if you ask the developers if they do any code profiling and get blank stares (yes, this happened recently when the Dude joined a mature team), you need to get them to look for memory, disk, and CPU bottlenecks with some of the excellent tools out there.
The surprising thing to me is how often really good developers just don’t know about how to check for, and code for, efficient use of resources in a computer. The Dude suspects that this is due to the rapid increase in computer speed, and the reduction in costs of things like RAM, SSD’s and very fast GPU’s. The Dude learned to program on the venerable PDP 11/70, in Assembly language, and on the Cyber 730 for Fortran back when you would take your object code, de-assemble it, and optimize the inside loops to maximize performance. A lost art except in the highest performance environments.
