10001110100110101
Over the years, I've learned that coding was not to difficult. I've had few major problems with writing code and building programs. I would say that coding would take up 20% of the work needed to build a program.
Debugging on the other hand, is a pain in the royal arse because they're not supposed to be there except that they are. Sometimes you get a few scattered here and there, but if you code like I do, you end up with plagues of biblical proportions. I'd guess that 30% of the work into a program is sucked up by this chore.
The final 50% gets thrown into the endless pit of work and time known as program support. Explaining how the program works, getting it to work on other systems, and figuring out why the program runs here but not there. Too bad there is a thousand miles away. Although some of you may throw some of this support business into catching bugs, I don't think so. It's difficult for programmers to account for every possible situation, so they get it to work on whatever system they have, try to make it as versitile as possible, and then ship it out before (but usually after) the deadline. The program is now complete. The ball is now out of their court, and into support's hands. If there are any problems with it, support people will have to handle it. At least until the next patch arrives (which is still "supporting" the original program).
I've been put into the inenviable position of development and support. I must say, I prefer development. It's irritating for me to hear when one of my programs/scripts don't work when I've tried my darndest to plug up every nook and cranny in the code so that a friggin blind monkey could get it to run. But it happens. I'm not perfect (although I believe that my code is).
So you hear about a bug. Now you have to figure out why it broke. You try it on your system. Hmm, seems to work fine here. You suggest an alternative. Nope, doesn't work. How about this? Nuh uh. You send a different build. Same problem.
I think support personel are in a high risk catagory for male pattern baldness. (Even the girl.)
Now the thing you learn when you program (but usually from experience) is that you have to trap errors. All of them. If any of those wily little errors escape from your grasp, then you've got a little problem. If more escape.. well, just hope they don't procreate. Trapping errors actually isn't that hard to do. Most programs will let you catch any errors and work around the problem on the fly. What you need to do however, is to catagorize and label each error. That would be like catagorizing every species of flea on your neighbor's dog armed with only a pair of chopsticks. It can be done, but boy is it a beeotch.
Ahh, I think that's enough ranting for now. I've got some code to fix..
Friday, February 02, 2001 at 10:18:11 (UTC)
You think bug fixing is bad.. wait until you hit code maintenance!
"You haven't seen this program in three years, but I'd like you to integrate the following features today..."
MJO