Sfoglio il libro di inglese e mi cade l’occhio su un esercizio svolto a metà. “Come mai questo non l’hai finito?””Perchè è suonata la campanella.”
“Non è da finire a casa?”
“Nonò, la prof ha detto che lo finiamo la prossima volta”
Poco convinto giro indietro di una pagina e trovo un altro esercizietto a metà. “E questo invece?”
“E’ suonata la campanella e non abbiamo potuto finirlo.”
“Ma come? Non è suonata mentre stavate facendo l’altro?”
“Perchè la prof ci ha diviso, metà facevamo un esercizio, metà l’altro.”
“E tu eri in tutt’e due le metà?”
“… no ho iniziato uno, poi ho smesso e ho fatto l’altro.”
“Ma non avevi smesso perchè era suonata la campanella?”
(a questo punto ho desistito perchè probabilmente saremmo potuti andare avanti per ore).
Complexily Complicated
The embedded muse is always filled with interesting links and articles. In the last issue I read this: Compared to what? about cost of firmware. In fact I think that the main problem we programmer face when trying to have our work recognized by non-programmers (usually those who sign paychecks) is that it is very hard to describe what we do to non-programmers. Going in details to explain how hard it is can be out of our reach.That’s like to say that programming (real programming, not integration or recompiling demo projects) has a non-intuitive grade of complexity.
This reminds of a recent project which I routinely failed to have the upper management appreciate the complexity, since they perceived it as a replacement for an electrical system (a couple of lights, buttons and wires). In fact the firmware equivalent of such simple system was completed in a short time. The rest of the time (actually quite a large amount of time) went in what couldn’t be done by a plain electrical system (graphical display, history, complex priority and communication management).