El título de Arquitecto desafortunadamente viene con un estigma porque muchos de ellos de alguna manera se metieron en el papel sin haber trabajado durante un número significativo de años como ingeniero. No saben cómo codificar y no saben cómo es construir software.
Sin embargo, el “papel” del arquitecto es importante. Aprecio mejor el papel ahora que no tenemos ese título en mi empresa actual. Existe una gran brecha en la responsabilidad de comprender el panorama general del producto que estamos construyendo y coordinar cómo deben interactuar los múltiples componentes y qué contratos deben cumplir para construir un sistema de trabajo.
Convertirse en un buen arquitecto lleva tiempo. No es algo que creo que pueda lograrse a través de la inteligencia pura. La mayoría de las veces, existe un desacuerdo entre ingenieros o equipos sobre cómo debería funcionar el sistema en general. Se necesita a alguien con fuertes habilidades interpersonales y técnicas para resolver estas disputas y, en última instancia, asumir la responsabilidad de tomar la decisión correcta y mantener a todas las partes involucradas comprometidas y respetadas.
- ¿Debe un buen ingeniero de software pasar a la vía de gestión para el crecimiento, suponiendo que sea igualmente bueno en gestión y programación?
- ¿Los ingenieros de software necesitan saber codificación?
- Si estoy tomando la introducción a la informática y las matemáticas discretas, ¿qué temas serán los más útiles para un aspirante a ingeniero de software?
- ¿Qué tipo de preguntas se esperan para la entrevista telefónica de Software Engineer en Google?
- Tengo miedo de estudiar matemáticas aplicadas porque quiero ser ingeniero de software. ¿Todavía está bien o debería cambiarme a ciencias de la computación el próximo año?
Imagina construir una casa desde cero. Incluso si pudiera obtener los constructores, techadores, plomeros y electricistas más inteligentes, ¿desearía que construyeran su casa sin acordar una arquitectura posterior?
En mi empresa actual, he abogado por el * rol * de arquitecto. Es un sombrero otorgado a los ingenieros de software senior y son responsables de diseñar una arquitectura para una pieza específica de funcionalidad en todo el sistema. Luego, los líderes de ingeniería de los equipos revisan su arquitectura y deben construir componentes que son parte de la característica. Volvemos sobre cualquier problema y llegamos a una solución. Esto funciona bien la mayoría de las veces cuando hay acuerdo, se vuelve más difícil si hay puntos de vista fundamentalmente diferentes. Ahí es donde finalmente necesitamos a alguien con la autoridad para decir: vamos en esta dirección. En general, si los equipos no pueden persuadirse mutuamente del diseño de un sistema, entonces cualquiera de las soluciones es buena (o mala) como la otra y hace poca diferencia. Lo más importante en ese caso es elegir uno y seguir adelante.
Diré que dejar las decisiones arquitectónicas en manos de los gerentes es una mala idea porque a menudo pueden verse tentados a usar una decisión técnica para ganar una batalla política / territorial.
La otra desventaja de pedirle a los ingenieros que construyan es que he descubierto que muchos de ellos no quieren involucrarse a ese nivel. Es aburrido e incómodo tratar de explicar conceptos a la gente y ganárselos en comparación con la satisfacción instantánea de escribir código que hace exactamente lo que le pides.
Así que ahí lo tiene: puede pasar sin un arquitecto, pero si tiene uno bueno en el personal, resolverá muchos problemas y, lo que es más importante pero menos obvio, evitará que ocurran aún más problemas al principio sitio.