Through the Looking Glasses

Through the Looking Glasses
←	Chapter 1. Introduction	→

Through the Looking Glasses

The developer sees and works with every software facet.

How it is seen by the user, the developer see during testing the software.

The way the software presents itself to the computer. The developer literally lives this facet of her software. The user forgives and finds ways around software problems. The computer never forgives nor does it seek solutions on its own. The associated activities are: coding, debugging and code inspection.

Good software requires a thorough understanding of what will be done with it. The intended usage –problem domain– must be analyzed before software can be written.

This analysis is often covered by a series of documents, known as specifications. Wherein a mix of diagrams and literal text describes the present problem and its solution embodied by the software code.

How it is seen by the Computer Owner (termed User). The »H«, for Human, in HCI.
How it is seen by the Computer. The »C«, for Computer, in HCI.
How it is seen by the Developer. There is no »D« in HCI. The »I« in HCI stands for Interface, but this interface only describes the first relationship between owner and computer. Not from the developer’s point.

Written languages, either as documents or code, allow synthesis as a means of problem solving. Any written text is prune to various interpretations, so is code –not for the machine of course. Pogramming languages are ill-fitted analytic tools for analysing the problem domain.

Whenever a program gets written, a simulacrum of the given problem is solved by the software. Worse, the successful analysis only exists inside the head of the developer. When a software loses its lead developer, the entire analysis –knowledge acquired during writing the software– is lost, too. The investment in the problem analysis is gone, too.

The Unified Modeling Language (UML), partially helps to overcome this problem, through visual analytic tools such as statecharts, use-cases and package diagrams.

The other Unified Modeling Language (UML) diagrams are meant for software construction and lead to the same synthesis inherent in every language.

Worse: Unified Modeling Language (UML) tools norrmally don´t generate code from their analytic diagrams. Often, the analysis is treated like an appendage to the software construction.

GUI-Builders are analytic tools: With a GUI-Builder it´s possible to analyse the visual and interactive aspects of a software to be. The developer faces her software during the entire design phase and thus strengthens her design skills constantly.

In some favored circumstances the developer is also an user of her software. This was the case for me, when I wrote Jeszra. I´ve use Jeszra throughout its entire development.

A GUI-Builder must loose its analytic benefits when combined with a code-editor. The authors of software tend to concentrate on the creation of software, knowledge acquisition is only seen as a byproduct of writing the software. This is perhaps a social phenomenon, developers are being paid for results and not for gaining knowledge.

←	↖	→
The Gestalt of Software	↑	Software Design and Construction

Copyright © 2009–2010 Arndt Roger Schneider