All right we have all seen bad applications. Not to pick on anyone vendor in particular, but the worst I have seen in awhile has to have been the new version of MS Word that came out Microsoft Office 2009. (I’ll save Vista frustrations for later.)
I do not know about you, but it took me a week of google searching to find out that the nice logo in the top left of the application was where all the old Save As.. etc functions disappeared to. Who thought that would be a good idea?!?!?!
Okay so we know how it changed, but why? That is the focus of today’s blog.
1.) Badly designed Applications are only badly designed from a user’s perspective. Which when you think about it is who all applications are designed for in the first place.
Another example (again not to pick on any one vendor) was the wildly unpopular changes to the security settings in Facebook? They made perfect sense if you are a computer programmer, but to a normal end user, it was too cumbersome, too hard to follow, and too hard to figure out. So once the complaints and confusion started to show up on other social media, more changes were triggered.
2.) When one has to face the wrath of the users, because the roll-out strategy or the documentation to go with the application is non-existent, that is when one truly finds out how bad it is.
Going back to the MS Word example, no where in the original documentation where you told how to find that logo. It was called a button, but to everyone I asked, and a couple of them are MS developers, they all said it was a logo to them too. If the people who write the software are confused, what does that do to the rest of us?
3.) When the business decides that it is better to get the product out the door because the delivery date is coming up, versus sending out properly vetted code, that is when bad applications are born. It’s like premature birth, it may feel good to deliver safely, but there’s a lot of nursing and care required afterwards. In fact bad applications have exponential cost, since the companies that buy them have to spend more money on service and addministrative fixes.
Why is it there is always time to fix it, but never time to do it right in the first place? Does a carpenter measure twice and cut once or cut twice and measure once? Which table would you prefer to sit at?
We see how bad applications are born and how profits are lost in false starts, endless fixes, overtime development, unhappy clients and returns. So how do we change it? Well, that would require a culture change.
Three Easy Any Company Can to Use to Develop Better Product;
1.) Ask the end users who are going to be using the application what the really need, not what they want. Then build it to their requirements, not the developers.
2.) Never let developers design an application without input from the end users. Developers know what not to do to break something. Users do not.
3.) When you plan out the project timeline, put in proper time to QA and Test the code before it goes out… Anyone remember the debacle around Vista?!?!?
It takes no more time to write a good application than it does a bad one. Unfortunately within the IT community we have come to accept badly written applications as the norm, which when you really think about it, does not make much sense.
We know how things should be, we are the people telling everyone else how to do things properly, so why are we the exception. The phrase that keeps popping into my mind is really quite simple…..
“Physician Heal Thyself!”
{ 0 comments }
