Payload
I had a strange discussion recently with some co-workers about what our software is for. I suspect that a couple of them thought the topic rather pointless, so I asked the question I ask myself most often when I design software: What does the user want to do? (I learned that question here more than ten years ago). Many of the answers were that the user wants to log on to the system and the user wants to monitor the system status and the user wants to be alerted if the system fails. No. These are the things we require the user to do. These are all overhead. In using Windows, for example, all this file management stuff and virus checking and installing and defragmenting and setting up security: it's all overhead. The payload, for me, is this: writing, reading, playing. If most of your software is for logging on and configuring and checking the status of the software and managing the software's files, there's too much overhead and not enough payload. What are the user's goals? Only if a feature directly helps the user achieve a goal, is it payload. Otherwise it's overhead and should be eliminated if possible.
4:38:59 PM 
|
|
