"D'Arcy J.M. Cain" <d...@druid.net> > One might also argue that divorcing the design from the code is the > problem in a lot of legacy code. See Agile Programming methods. Now > you could say that there is a design step still in talking to the > client and making a plan in your head or in some notes but that's like > saying that Michelangelo was done creating after discussing the Sistine > Chapel with Pope Sixtus and that the rest was just a house painting job.
How do you know that it was not exactly like that - he did, after all, take a much longer time than expected to complete the job - just like a house painter that gets paid by the hour. :-) It is also unreasonable to assume the opposite fallacy - that he was in a creative frenzy from the start to the time at the end when he was cleaning his brush after applying the last spot of paint. But it is a valid point - it is often difficult to draw the line between the design and the implementation - and one of the reasons that we all like to program in python, is that it is almost a language that is a design language that can also be run directly. - I have lately been doing stuff like writing rough prototypes using python syntax to serve as designs for some of the assembler thingies I do. If you muck around a bit at the lower level, you will also be more aware of the dichotomy between the design and the implementation - in python, it is not obvious at all. In assembler, it is glaring. But in either place, if you get it wrong, you suffer. - your programs cripple along, or they hardly do what you thought they would, and they bear no relationship with what the customer wanted. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
