Programming is Designing is Architecting is Designing is Programming

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.

No comments: