Comparing the map and reality in most circumstances reality wins.
If the sentence above feels ridiculous I can say I have worked with a project leader who thought otherwise.
( a friend of mine said “comparing the map and reality, reality wins. because that is where you are” )
>Do not write reusable code. Write rewritable code.
With reusable code I think of code that without retesting can be used in new ways. “Without retesting” means it has been tested for this “new” way of use beforehand.
The problem is that the code obviously has been written and tested for a usage not applied by the time of writing. To me it seems like a waste of time.
One could write the code reusable but not test it for any other usage than the present. I would recommend this since the source will then contain untested code which even might be interwoven with the tested. Mixing tested and untested code and increasing the complexity of the code by handling possible future situations will make the code harder to understand.
Better then is to write the code so it absolutely fits the needs and instead put some time into making the code simple and clear. Comment it even!
These thought boils down to
Simple code – easy to update.
Complex code – hard to update.
So instead of writing an if statement testing for a flag or inheritance or whatever insert a comment “If you plan to do this or that – here is the place to write the code.”
I got the coding rules for a big company. 200 pages. I put it to the side with the thought “Noone else has read it either.”
Too little documentation, read or unread, is better than long that is not read.
I talk about the three different roles like this:
– Programming: coding, implementing algorithms.
– Designing: deciding algorithms, choosing protocols, constructing class relations.
– Architecting: making the code and machines work with the business rules.
When a programmer selects to write one piece of code instead of another he makes a (hopefully) aware choice of which code will be the best today and tomorrow. (These two aren’t necessarily the same.) By this code he influences the ways algorithms will be implemented.
When a designer selects a protocol for another he also sets some technical limits. Different protocols are more or less easy to update, debug and trace. This influences the architecture.
When the architect decides for something he has to consider why it should be done, how and by who. (whom?) Every architectural decision must be implemented (or better – does not have to be implemented) somehow and this leads to a design decision in turn.
Now, when the designer decides to use a solution it has to be implemented. It can only be implemented by the programmers. Considerations must be taken for why, done and who.
This boils down to a programmer has to know how to design. A designer must know how to architect. An architect must know how to design. And a designer must know how to program.
I would also say that a good programmer knows how to architect and an architect how to program.
Code written might have architectural implications.
Even comments have design implications.
Strong typing gets rid of lots of runtime errors. Why do script languages always use weak typing? I really don’t see anything good coming out of it.
A friend of mine, mainly a Java and Python programmer, defended Python’s/scriping’s position by telling me how fast it is. He compared the turnaround for a Java web project and a Python ditto. So I see his point, it was quite cumbersome to update the Java solution (I don’t remember the environment), but I have yet to find such a complex situation in any solution I have built for dotnet or VB6.
I doubt all Java solutions are as complex as his example.
Which sort of gets me back to the first paragraph. There is no reason for a scripting language to be weakly typed and hence more error prone.