- Engineering Complexity
- Birth of Murphy for Java
- People = Problems
- Education Through Pain Management
- The Twenty-Cent Solution
- Fraternal Clones
- "We Lost the Napkin"
- The Devil in Blue Jeans
- Jack and the Beanstalk
- The Slashdot Effect
- The Funhouse Microphone
- That "New Car" Smell
- If I Can See It, It Must Be Wrong
- The Ugly American
- Murphy's Law
- Use Egg Cartons
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
If I Can See It, It Must Be Wrong
Law: If people are involved, duct tape won't fix it.
Q: Is there a user interface and/or report generation?
The most deadly failure is when the customer hates your software. If it doesn't suit the customer's needs or is incompatible with their process, the software is worthless—or at least a pain to use. There are many causes, from pride, presumption, arrogance, laziness, and lack of vision to simple misunderstandings. Any flaw of character, intelligence, and wisdom can cause an application to fail to meet users' needs.
We have a full toolbox of ways to help make sure that our users' needs are met. They include gathering and validating user requirements, user tests, and others. Nevertheless, the problems are that these tools are co-opted, subverted, modified, and ignored.
Let's state two basic tenets of software that are often ignored:
Software is written and designed by people.
People use software.
Errors can come from various places:
Users make typos or other mistakes.
Users and designers may not have enough knowledge to make the right decision.
Everyone has hidden agendas, whether coldly calculated or subconscious, which lead to incorrect designs.
When people interact, egos, personalities, alliances, and emotions affect design decisions.
Time, budget, tools, experience, and politics affect the quality of work and thus the design.
By now, you might think that a psychologist should run a software project. I must admit that a study of human psychology helps; I can vouch for that from experience. The problems are not terribly difficult in many cases. The key is to look at symptoms and apply workarounds and backups. Most importantly is testing the software as early and as often as possible with actual users (not managers, marketers, or salespeople).
Low Risk
We validate the design with the users on a regular basis and we give beta copies to real users on a regular basis (risk reductions listed below are also applied).
No user interface; this software only operates with hardware.
High Risk
We don't let software people talk to customers.
Users need to be trained because they might make mistakes. (In other words, our software is full of holes and difficult to use.)
The development team has no previous experience with user interfaces or report writing.
The user interface must be flashy and a unique experience. (Form has a higher priority than function.)
Risk Management
The development schedule should be iterative and completed versions created every couple of weeks for use by users.
Functional capability must be designed, developed, and tested before creative design is applied.
Use user input to prioritize features, giving a higher priority to features that are currently part of the users' current process.
Track user mistakes and eliminate the possibility of making them.
Make the design tolerant to common mistakes.
Automate repetitive tasks.
Divide the project into functional development and artistic development.
Functional development is a higher priority than artistic or "cool" features.