Architecture is not laying bricks [Or: Programming is not writing programs]
Because of the history of computing it is thought by many that writing code is
programming. The introduction of the first online system, and then the
microcomputer, bth offering the possibility of direct 'hands-on' developement
of code, has exacerbated this problem. The software developer is encouraged to
develop programs at a keyboard and screen - modern software tools encourage
this approach, as witnessed by the sales of C developement tools.If programmers
are lucky enough to work for an 'enlightened' company they are provided with a
complete program developement environment including tools for writing,
checking, debugging and managing code. Just as typing in text has very little
(or nothing) to do with writing, coding a program has little to do with the
art, or even science, of programing. Mathematical ideas have been applied to
the problem of writing crrect programs for over twenty years and this has
produced techniques which can be applied by the average programmer to improve
their programming ability.
It is worth considering again the standard parallel often quoted byb teachers
of computing: that of constructing a building - in the sense of building from
concept to bricks and mortar. This activity is not usually started by just
taking delivery of the component parts and then laying one brick on top of
another, before the overall design of the building has been considered. Though
those of us who live in moern houses may not believe this, some sort of design
process has occured and the result of this is used to drive the building
proccess.
This particular analogy can be taken further. Early architects and
stonemasons learnt by experience. They knew - usually by trial and error - that
a particular set of strategies worked, so next time a similar building was
constructed, the known strategies were used. Our early architects occasionally
had major set-backs, for example, the cathedral fo Chartes collapsed; it was
larger then the last cathedral which had been built and unfortunately the
techniques did not quite scale up to the bigger problem! The solution of course
was to rebuild it using the existing strategies but extended to handle this
'larger' case. In progamming one can see this technique reborn with the idea of
defensive programming: the programmer doesn't quite know what is going to
happen and so adds extra 'twiddly bits' to the code to deal with the unknown
situations (which is more or less what the developers of the new cathedral at
Chartres did). Unfortunately even the apporach of the stonemason may not be
used by a programmer: each new programm is written from scratch, even
strategies taht are knwon to work are not used, each new 'building' is treated
as a new problem.
It is rumoured that some early archiotects used mathematics to help desing
their cathedrals. In that period the mathematics that worked came from the
Islamic world and, of course, was considered heretical and so had to be done in
a 'dark corner' - perhaps these architects calculated the properties of their
building before constructing them, and thus woudld have some idea of their
shape an strength before construction began. Today there is a small minority of
programmers who use mathematics to develop their programs; where are the dark
corners whre they work to be found?
The main difference between architects of buildings and architects of
computer systems is that if the former go wrong during the building process
their result is a pile of rubble, for the latter the offending component is
just modified. Imagine how different the history of architecture and civil
engineering would be if it were possible to modify an offendingf part and then
to have the edifice instantly rebuilt. Because engieners cannot afforet to have
a component fail they use the science of mathematics plus some well-established
rules (strategies, experience) to hepl to contsruct building which do not fall
down. Progammers should adopt a similar approach when builing their programs.
The first software crisis occured when computers were large and powerfull
enouyghj to run progams taht are bigger than one person can manage - a team of
programmers that understood the developement process needed to work together to
produce a working computer system. Many such teams did not understand software
developemetnand the result was the first software crisis in 1968. It should be
noted that the first microcomputers were about the same size and power as the
old computers and the programs that ran on them were about the size that one
person can manage. As microcomputers have increased in power, the lesson of
writing large programs had to be learned for their full potential to be
exploited. THe fact that software developement for microcomputers needs a team
was discovered in 1984, and thisled t a second software crisis. We are probably
heading towards the third when the one-man programmer currently working on
spreadsheet and dataase mactos grows to a team of programmers that need to
work together to develope such systems.
One point is clear from historuy of prgamming, we are quite good at
developing small programs, but terible at writing large systems. A knowdlege og
the hteoruy of programing would make us very good at writing small programs and
could throw some light on the developoemtn of large systems that were
corrected.
Perhaps at present it is too much to expect programmers to learn all the
necessary mathemtaics that forms the foundation of programming so that they can
develop programms more effectively, but there is a reason why the teachers of
programming should avoid understanding the theory of programming It begoves us
to learn the mathematical background to our subject and to extract some of the
ideas to teach to the non mathematicians among our students. Before teaching
any specification, developement, or pgramming techiques the underlyuing
mathematics should be fully worked ods taught tday have little or no
mathematical background, or have one which has not been properly worked out.
This leads to two problems. First, the technique could be wrong, and second,
when the sophistication of the people using the technique reaches a level where
they wish to know the theory behind it so they can understand and use it more
eficiently, they discover that this background does not exist - the cathedrals
have been built on sand.
-- Derek Andrews
Tento clanek mne velmi zaujal a myslim si, ze neuskodi si ho precist nikomu -
obzvlaste tem z vas, kteri tvrdi, ze matematika nema s CS nic spolecneho a v
progamovani vidi \"buseni do klavesnice\", popr. znalost syntaxe nejakeho jazyka
(...as witnessed by the sales of...
Clanek byl prevzat z knihy \"Programming Language Choice\" z nakladatelstvi
International Thomson Computer Press. Byl tez otisten v International Series of
Software Engineering v roce 1996.
P.S. za pripadne chyby se omlouvam, ale mne opisovani vazne moc nebavi...Derek Andrews, prepsal neologism
