Thank you for publishing Mitchell Kapor’s article entitled “A Software Design Manifesto” in January 1991 issues. I applaud Mitchell Kapor’s comments for their enlightened thought, courage of conviction, accuracy, and timeliness. Issues he has addressed needed public exhibition in order to shake up the personal computer and software industries. Mitchell and I are part of an imperceptibly small group in the software engineering community that completely comprehends and embraces the “software design viewpoint”; thus, we battle daily against software mediocrity. My background in industrial design and consumer product development management is the foundation for my venture into the software design and engineering area.
Consumer product development focuses on user requirements. Designers learn sensitivity, adopt the user needs as their own, empathize with the user, and become the user in order to understand the user’s needs. Thus, state-of-the-arts technology is forced to conform to the humanness of the user. Unfortunately, the opposite situation manifests itself in MIS Departments, and software consulting firms.
Today, those persons who relate to the mechanics of programming are given the task of defining and addressing the humanness of the user. Therefore, the user gets the expertise of the analyst/programmer’s coded perception of the user’s needs. The depressing part of this is situation is that neither the user nor the analyst/programmer are aware that the software could be more than it is in the present form. The reasons for this situation are:
- First, analysts and programmers lack marketing or scientific research experience; hence, they cannot ask the right questions of the user to get the correct information for development.
- Second, they cannot or do not communicate the versatility of the programming language to the user.
- Third, analysts and programmers lack time, motion, and methods, and human factors and perceptual analysis experience; thus, they do not observe and evaluate the user’s activities as they relate to software requirements.
- Fourth, I have sensed the following attitude among some software engineering persons and MIS departments, which is: No one outside of our discipline can contribute much to the software development process.
- Fifth, society promotes the following myth: The personal computer and programming are both difficult to learn and mysterious.
However, the user must assume some responsibility for software design failure. Some users are afraid and are uncomfortable with computer or software development. Today, the PC is important to productivity in the workplace yet employees still resist it. Typically, the attitude is: Do not teach me more about computers than I need to know in order to get my job done. Because users refuse to learn that little extra about the software, continue to make the same mistakes, which increases their frustration. If this computer phobia could be overcome, users would make ideal candidates when polling for software ideas.
Sometimes users do not appreciate the value of the data they possess. Since users have only a cursory relationship with the computer, how can they ask for software products that meet their needs?
Mr. Kapor’s article supports a philosophy I have advocated for years, before I founder Alexander PC Systems, a software engineering firm. When we begin a software development project, the marketing and user research is complete first. Then a design concept and matrix structure is created. The design concept is user tested and perfected before the coding is started.
We are obligated to overthrow traditional software development methods. The losses from mediocre software must cost millions of dollars each day. Current practices need to be replace with “user-focused software development” or in Mr. Kapor’s words, a “software design viewpoint.”
Bryan R. Alexander
Morristown, New Jersey
|
