writing better software
A guy who worked as a support tech and a developer made a list of 5 reasons why programmers should have tech support experience. A lot of what he says boils down to thinking about the end user.
As a programmer I want to write software that is easy to use, but that’s subjective. Is it better to have a program attempt to do everything automatically or let the user decide? If it works, great, but if the user wants to do something the programmer didn’t think of, there are usually problems. There has to be a balance between being easy to configure and easy to use, but finding that balance is hard. Ogden Nash made a good point, although he wasn’t referring to software, when he said, “Too clever is dumb.”
This next quote is probably more true than some people realize. “That’s the thing about people who think they hate computers. What they really hate is lousy programmers.” (Larry Niven and Jerry Pournelle in “Oath of Fealty”)
I have to say, the part about writing good error messages is true (#3). Our IT guy has to spend his time between five offices in four states, so his time is precious; Every time I get an error, I can’t depend on catching him free (or even in this state). Knowing how prone to problems some programs are, *cough* Microstation *cough*, it would really help if I could figure out for myself what the problem is and be able to fix it myself. I’d spend a lot less time with the computer down waiting on the IT man that way.
And #4 – the hidden menus in XP? Arrg. I hate hidden menus.
I’ve been both tech support and a developer, and I also have a unique perspective in my job now, being somewhat of a liason between Sales and Engineering. I try to keep the sales guys realistic, while at the same time try to figure out what the company is doing.
I had to redo an application that a co-worker wrote for one of our customers. It was too confusing for the end-user. In the words of my boss, “He made the space shuttle when they needed a Yugo.”
That’s where requirements documentation comes in. The Req Doc should state who the end user is and what level of experience they should have. Dumbing down software can be frustrating for the developer, but I’ve also been in the situation where I had no idea what I the app did. Something that could have easily been avoided with a few lines in a Man Page or Error message.
Well I have a question I’ve been trying to get an answer for but, anyway how excalty do you make software what is the processes?
Tremain: Any sort of worthwhile answer would not fit very well into a comment here. I would recommend you check out a few books on software development from the library, especially ones that discuss how to do iterative development, my preferred way of working.