4 ms·

> But the right way to do it is to have smart actual users talking directly to smart actual devs. I find in my own software that the best thing to do, if you'r

> But the right way to do it is to have smart actual users talking directly to smart actual devs. I find in my own software that the best thing to do, if you're improving an existing process, is to watch (or participate in) the current process, with an eye toward the parts which waste time or irritate people. In any case, after the initial study, it's crucial to back out of the details of the process and think about the overall goal to be accomplished. You don't want to waste effort evolving a process that's been badly distorted by existing software, when you could simplify the process immensely by writing something directly focused on the actual goal. This is an intensely creative/intuitive phase of the process, so it often takes several iterations (from a fresh state-of-mind each time). Once you think have the perfect solution, go back and make sure that it solves all the problems noted in step 1. If it doesn't, try again.

stcredzero 18y ago
By "talking directly" I mean going to the floor where the software is actually used and hanging out with the users. The bandwidth is so much higher. Talking to them in a meeting room with no computer is almost a complete waste of time.
joshwa 18y ago
Of course, that assumes you are actually permitted to change the process. The project I'm working on has the constraint that while we are allowed to write less-buggy software that catpures the existing process more effectively, we are not allowed to propose changes to the existing process (which evolved around the existing cruddy software-- 10 years of accumulated process and "feature" cruft, now cast in carbonite). Corporations sometimes have a funny definition of "risk." Sometimes, Risk(changing to a sane process) < Risk(reproducing unnecessary complexity of existing process).
- stcredzero 18y ago
  True story: A friend of mine wrote software for NASA. There was an old control system for something that had as its interface a 9 key keypad a numeric readout and something like an enter key. The system was modernized, and its software was ported to Unix workstations. However, to keep it compatible with the operations manuals, the new GUI interface just simulated the keypad and numeric readout. (This is not software that my friend wrote. He ported the "numerical integrator" program used to track the Space Shuttle in orbit and calculate abort trajectories during launch. And yes, he showed me the program with the keypad! Another thing: as I was walking around at JSC, I saw a "Unix for Dummies" book back there!)

stcredzero 18y ago

By "talking directly" I mean going to the floor where the software is actually used and hanging out with the users. The bandwidth is so much higher. Talking to them in a meeting room with no computer is almost a complete waste of time.

joshwa 18y ago

Of course, that assumes you are actually permitted to change the process. The project I'm working on has the constraint that while we are allowed to write less-buggy software that catpures the existing process more effectively, we are not allowed to propose changes to the existing process (which evolved around the existing cruddy software-- 10 years of accumulated process and "feature" cruft, now cast in carbonite). Corporations sometimes have a funny definition of "risk." Sometimes, Risk(changing to a sane process) < Risk(reproducing unnecessary complexity of existing process).

stcredzero 18y ago
True story: A friend of mine wrote software for NASA. There was an old control system for something that had as its interface a 9 key keypad a numeric readout and something like an enter key. The system was modernized, and its software was ported to Unix workstations. However, to keep it compatible with the operations manuals, the new GUI interface just simulated the keypad and numeric readout. (This is not software that my friend wrote. He ported the "numerical integrator" program used to track the Space Shuttle in orbit and calculate abort trajectories during launch. And yes, he showed me the program with the keypad! Another thing: as I was walking around at JSC, I saw a "Unix for Dummies" book back there!)