Architects are programmers
We must notice that architecture is a subset of design which implies that an architect is a designer. Now, if we agree that programmers are the designers of software then a good programmer that is capable of designing this subset, is an architect. Also notice that there are no good architects that are bad programmers. Being a good programmer is a prerequisite for being called architect.
Of course there are other tools to design software (diagrams, etc), but a programming language is better as its product is the only design representation that is directly interpreted by the computer and the only one that has a 1 on 1 relation between what you expect and what you get.
Used correctly, they are better at communicating a design than the alternatives.
So architects should program but they also should do it in the same physical space as the rest of programmers. Not only because they have to communicate their ideas but also for two extra benefits:
- Feedback.
Probably the most essential characteristic of software design is that it evolves by iterating. Even when doing waterfall, you evolve and iterate (the problem is that you stop too early doing so and you do it on paper). This evolution can only be done with realtime feedback and you won't get feedback if you are not inspecting and touching the guts of your child.
You can only assess the correctness of your initial "paper level architecture" with the detailed "code level architecture", you should have a deep understanding of the most real representation of your architecture so you can be able to gather immediate feedback both against interpretation errors when some developer didn't understand you and against your own errors. Even if you are errorless (I don't believe that), feedback lets you learn about the domain and improve continuously your design. - Maximizing transfer of expertise and knowledge.
If an architect is just a good and respected developer, then why not transfer its merits to the teammates. This would end up being a win-win situation because they'll keep improving and they know they will be responsible for the general improvement. The waste and problems that represent using programmers as if they were code generation tools is as silly as having not programming architects. Their design abilities must be improved. If they can't improve, well, then they are too stupid and risky even as a code generation tool, so don't hire them if you don't intend to use them as architects.
The separation problem
Divide and conquer it's a great heuristic. But if you fail to spot the point in which you should stop dividing, then it's counterproductive. Some things belong together. And when those things are split you'll find problems.So if we have an architect that is not involved in programming we'll get two situations:
- We have an excellent programmer, probably the best in our company, that is being used only for writing word documents and making presentations and diagrams. This is any design representation you imagine except the one in which he is good at and at the same time the one that is the more important and cannot be skipped. Yes, this is the one that is least understood by other departments of the company, but the architect role should be constructing software, his main target of communication are the programmers from the trenches. Communication with the rest is secondary.
- We have a bad programmer that was choosen for some reason to make the architecture of the system. Let's not extend on this for obvious reasons.
2 comments:
Daniel,
¿Jode mucho que escriba en español?
Ya alguna vez he escuchado gente hablando de ambas etnias de la informática. En principio, yo diría que hay pequeñas diferencias entre arquitectos y programadores. Los arquitectos son la evolución de programadores, o son gente que conociendo mucho de tecnología, saben lo suficiente de programación como para poder arquitecturar software.
He conocido a lo largo de mi experiencia laboral a gente que es muy buena picando código pero que nunca la pondría diseñando la arquitectura de una aplicación.
Crear una arquitectura lleva mucho de visión y requiere poder lograr niveles de abstracción que no se logran si se está metido entre código todo el día.
Es como el huevo y la gallina. El gallo elige una gallina que sea digna de empollar y después de eso vienen los huevos y los pollitos. Pero si el gallo no dedica tiempo a estudiar el gallinero desde arriba, puede terminar intentando con una oca.
La solución que tu comentas no me parece mala siempre y cuando los arquitectos puedan ayudar a la fábrica a lograr los objetivos de los analistas de negocios. En sí, es lo que hace un consultor en cualquier industria.
Hola Federico.
Prefiero un poquito más el inglés para poder interactuar con la mayor cantidad de gente posible, pero todo bien.
He conocido a lo largo de mi experiencia laboral a gente que es muy buena picando código pero que nunca la pondría diseñando la arquitectura de una aplicación.
En eso estamos de acuerdo porque si un diseñador solo es bueno picando código, no es un buen diseñador, yo tampoco lo pondría a diseñar la arquitectura. Pero si su código es suficientemente bueno representando los niveles de abstracción requeridos, entonces si lo pondría como arquitecto. Lo ideal claro, sería que todos fuesen capaces de ser arquitectos, aunque solo a alguno de ellos se le asignara el rol, más necesario por un tema de coordinación que por capacidad.
Crear una arquitectura lleva mucho de visión y requiere poder lograr niveles de abstracción que no se logran si se está metido entre código todo el día.
No estoy de acuerdo en que no se puedan lograr buenos niveles de abstracción utilizando código fuente.
La analogía entre lengua escrita y código fuente es muy útil en este caso.
¿Que pasaría si trataramos de comunicarnos sobre algo volado como la existencia de Dios únicamente con diagramas? No nos entenderiamos, podriamos hacer suposiciones de lo que piensa el otro pero siempre sería eso, una suposición. Esto es porque el lenguaje elegido no es suficientemente rico. Lamentablemente eso es lo que pasa en la mayoría de nuestra industria, con excepción de las empresas que usan metodologías ágiles.
Para hacerme entender no tendría problema en apoyarme en todas las representaciones que pudiera encontrar para comunicar mejor mi idea, es posible que incluyera algun diagrama, pero solo como apoyo, en las letras estaría la representación principal de mi idea.
Es como el huevo y la gallina. El gallo elige una gallina que sea digna de empollar y después de eso vienen los huevos y los pollitos. Pero si el gallo no dedica tiempo a estudiar el gallinero desde arriba, puede terminar intentando con una oca.
Estoy de acuerdo. Veo ese tiempo dedicado al gallinero corresponder en software al tiempo dedicado al diseño de alto nivel del sistema, diseño realizado en código fuente por supuesto. Es que nuestra descendencia es demasiado importante como para dejarla en manos de unos cuantos dibujitos!!
La solución que tu comentas no me parece mala siempre y cuando los arquitectos puedan ayudar a la fábrica a lograr los objetivos de los analistas de negocios. En sí, es lo que hace un consultor en cualquier industria.
No veo a los arquitectos como ayuda de la fábrica, los veo como miembros escenciales de la fábrica. Pero es verdad que es lo que sucede en la industria, lamentablemente.
Post a Comment