Engineering Ethics Problems in a Developing Country - Ethical Engineering for International Development and Environmental Sustainability - page 246

6.2 Solving Hardware and Software Problems Together

Leading Designer 4 was educated in computer hardware. Most of the projects he led
involved advanced applications of ICT. A major part of the design and development
work involved programming, but some hardware design and development work was
generally also required. This work was carried out under the control of Leading
Designer 4. Despite the narrow specialisations common in the West, this was gener-
ally not very difficult for people educated and skilled in computer hardware.
Where possible, hardware and software designers were involved in each other's
work. The detailed design and development work was carried out by competent staff
with the appropriate specialisation. However, their awareness of the problems and
perspectives of their colleagues improved and speeded up the overall design process
and avoided unnecessary conflicts between hardware and software designers. The
lack of these conflicts had the further advantage of avoiding the need to involve the
PoP managers with limited knowledge and experience of either software or hard-
ware in solving them. The involvement of managers without appropriate expertise
led to the failure of a number of large-scale ICT and automation projects in both the
COMECON and other countries. However, none of the projects led by Leading
Designer 4 ended in failure and the resulting systems were all low cost.

6.3 Adequate Technical Documentation

Good technical documentation should be considered part of standard good practice.
It is required to enable both the designers and others to return to and understand the
work at a later date. This is particularly important, as in the case of Leading Designer
4, when a designer may not be available for the full duration of a project. Therefore
Leading Designer 4 was careful to ensure proper documentation to facilitate the
work of his successors in modifying or extending the system.
In the case of hardware, the prerequisite functional, block and circuit diagrams
were drawn up without any objections. However, young and inexperienced pro-
grammers sometimes protested about the need for program flow diagrams on the
grounds that (1) they were not needed to write the program, (2) drawing them was
time consuming, (3) a code in a high-level language is the equivalent of a flow
diagram and (4) flow diagrams are obsolete.
However, flow diagrams are required to support the final debugging phase rather
than for writing the initial version of the program. Debugging might take place a
year or more after writing the program, particularly for large-scale systems, and
probably in the difficult conditions of the actual application. After this length of
time, even the original programmers are unlikely to remember their solutions and
therefore to find flow diagrams very useful. This is even more important when fur-
ther development of programs is carried out by other programmers, for instance, by
the users of the application. The availability of detailed flow diagrams facilitates