The subject line no doubt sounds like heresy in some quarters, but I have my reasons. Software developers typically get pretty fast workstations with multicore processors, lots of memory, big displays (and/or multiple displays), etc. It makes sense from a productivity standpoint. The problem is that in many cases it disconnects them from their user base.
Case in point: I recently downloaded the (free) academic version of CPLEX Optimization Studio 12.2 from IBM and installed it on my home PC. My home PC is a one-lung eMachines box running Win XP (and hence a gaggle of defensive programs -- antivirus, firewall, etc.). I do "serious work" on other, faster machines (running Linux), but this one is good enough for handling mundane chores, including some programming. I have both the Eclipse and Netbeans IDEs on it (sorry Eclipse fans, but so far I haven't found any Eclipse tools for building GUIs that match Netbeans).
So I'm looking for the documentation for CPLEX 12.2. In past versions, this would be some combination of HTML files, PDFs and (on Windows) CHM (Windows help) files. In the latest version, though, they've taken a different route. The Start menu has links to various help entries, but they all point to the same thing -- they launch the help component of OPL's IDE. In other words, to look up anything, I have to launch a stripped/modified version of Eclipse, which can take between one and two minutes on my PC. (After the first launch, subsequent launches go faster.) Between the IDE and the instance of Java it runs on, it eats upwards of 130MB of RAM, which seems like a pretty big footprint for a help browser, particularly if I've got a programming IDE going (both Eclipse and Netbeans run on Java themselves), a web browser and maybe an e-mail client open, etc. I have to wonder whether the developers would have gone with an IDE-only help system (no separate HTML or PDF docs, no CHM files) if they'd been forced to use it themselves on a system like mine.
There may be a lesson here for OR people, too. I think sometimes we over-engineer solutions (I know I'm prone to this) because we're comfortable with specifying mutation rates for genetic algorithms or deciding whether to use dual simplex or barrier algorithms. In our case, the key is not so much to "walk in the user's shoes" by living with the user's resources so much as to put ourselves in the user's head and see how much of what we're putting in front of them would generate a big "huh??".