Today I just want to talk about something that is pretty obvious to most people, but I hope to give you a few new ideas on it anyway. The topic today is idiot proofing your application. Now, let me go on record by saying idiot proofing your software is pretty much impossible, however, you still need to you best. I had a friend that used to tell me, “you can monkey proof your software all you want, but they just hiring better monkeys”.
So do you just run through it once, and call it good since you know it’ll be broken anyway? of course not. For me, this has always been a challenge. I’m part of a small business, and I’m the lone developer. That means, I’ve gotten really good at fixing the things I know will happen, but it also means that I tend to get tunnel vision. I believe it a common thing among developers, but the key is to avoid that trap. So here are some of the ways I’m trying to improve my own products…
1. Get someone that knows nothing about product to play with it. If I could get her interested, my wife would be a perfect test subject. She doesn’t use SAP, she knows nothing about service, but she does understand IT and software. By getting someone with no idea what is supposed to happen means that they will push all the buttons you never expected anyone to push. They will also look at it from a purely aesthetic perspective, something that I don’t do as well.
2. Next, if you can, get someone that isn’t good with software, but understands the business. this will give you the true test if you got the right info. If someone looks at the information generated, and says “this would help me run my business”, then you’re onto something.
3. finally, get another developer to look at your stuff. they’ll look at some of the ways you’ve done things and ask “why?” Often, we know a way to do something, so we don’t look for better ways. Often I’ll go to someplace like tech-ed or even a blog post and notice a strange piece of code. I look at it closer, next thing you know, I’ve found a better way to do something 🙂 The problem is that I don’t have the time to reveiw everything, and I’m biased, so I don’t see anything wrong with my approach. But… if someone else asks why did I do this, instead of that? well, it forces me to look at my stuff and either explain why it had to be done this way, or I may say… hmmmm, that’s a better way. Now I know a new way to do it. ha ha ha
The last point is to do this early and often in your development cycle. Point #2 is really something you should get before you even start programming. Sketch what you’re thinking, and show it to a business person. Ask if it would help… if not, why bother?
Anyway, this has been on my mind lately, so if you have some other good ideas, or are interested in playing with anything I’ve done, I’m always interested in having another set of eyes look at my stuff.
thanks,
Mike
As always, thanks for reading and don't forget to check out our SAP Service Management Products at my other company JaveLLin Solutions,Mike