Como arquitecto de software, ¿debo centrarme tanto en analizar los registros y corregir los errores de otros?

Desde mi graduación (finales de 2005) estaba trabajando para la misma compañía que un ingeniero de software de c ++. Hace un año fui promovido como arquitecto de software, pero me he visto involucrado cada vez más en la calificación y la corrección de errores, soporte de nivel 2.

El 50% de mi tiempo lo pasé en Notepad ++ analizando los registros del software e intentando descubrir qué salió mal. El 30% corrige los errores de otros y el resto (si lo hay) revisa el código de espagueti de los desarrolladores.

Empecé a odiar este producto y a pensar en una estrategia de salida de esta empresa.

¿Qué crees que puedo hacer en esta situación? ¿otro arquitecto de software todavía corrige errores en el código?

La mayoría de las personas generalmente está de acuerdo en que un Arquitecto de software debería involucrarse principalmente en el diseño de alto nivel, establecer estándares, elegir herramientas o marcos, evaluar productos, implementar prototipos y Prueba de conceptos, y capacitar y asesorar a los desarrolladores

Sin embargo, la realidad es que el título a menudo puede ser una cita política para un desarrollador, un título especial otorgado a los desarrolladores líderes de proyectos, o incluso algo tan simple como una solución de gestión de recursos humanos para contratar a un desarrollador muy necesario con un salario o tasa que Recursos humanos o la gerencia superior considerarían inaceptable el título de desarrollador de software o ingeniero de software.

En otras palabras, los títulos son en su mayoría sin sentido.

El artículo de Wikipedia define al arquitecto de software como:

un programador de computadoras que toma decisiones de diseño de alto nivel y dicta estándares técnicos , incluidos estándares de codificación de software, herramientas o plataformas ...

Dado lo anterior, sus estimaciones "50% de mi tiempo dedicado ... analizando los registros de software ... 30% reparando los errores de otros" lo ubican muy lejos de lo que normalmente se espera que haga el arquitecto de software.

• Yo diría que arriba hace que el título que te dieron sobre 50+30=80%falso.

Tenga en cuenta que, per se, actividades como analizar registros o corregir errores de otros podrían ocupar legítimamente parte del tiempo del arquitecto, siempre que sirvan para el propósito principal de este rol, es decir, tomar decisiones de diseño de alto nivel y establecer estándares técnicos. En realidad, este es el caso para cualquier tipo de desarrollo de software / mantenimiento / actividades de prueba.

Por ejemplo, si el análisis de registros lo llevara a una idea de cómo facilitarlo, mejorando el diseño, las herramientas o los estándares de codificación, este sería un esfuerzo perfectamente justificable para un arquitecto. Del mismo modo, podría estar completamente bien que el arquitecto se ensucie las manos arreglando errores particulares, siempre y cuando esto resulte en mejoras específicas de diseño / proceso que conduzcan a una menor tasa de errores, etc.

_{En una nota un poco más positiva, su pregunta demuestra al menos una habilidad que es bastante importante para el arquitecto: la capacidad de clasificar diferentes actividades y rastrear los esfuerzos dedicados a ellas. Considere agregar a su "caja de herramientas" habilidades complementarias para resumir sus observaciones y estimaciones y comunicarlas claramente, especialmente en la escala de gestión. :)}

Como arquitecto de software, ¿debo centrarme tanto en analizar los registros y corregir los errores de otros?

¿Supone? si y no. Usted está a cargo de la totalidad de la calidad del producto y la ruta de evolución: haga que funcione mañana, pero también que funcione el próximo año.
¿Eso significa prestar una mano amiga para resolver problemas difíciles? Absolutamente, al menos yo sí. No puede hacer que el producto funcione mañana si sus clientes lo dejan.
¿Eso significa que deberías dedicar TODO tu tiempo a eso? Absolutamente no. Usted está a cargo de la TOTALIDAD de la calidad y la evolución. Dedicar tanto tiempo a perseguir problemas es contraproducente.

Se supone que eres proactivo:

1. Inicie planes de educación para que otras personas (dev / support) puedan levantar la carga. "Enseñar a un hombre a pescar" y todo ese jazz.
2. Invente formas y desarrolle herramientas para admitir un análisis de defectos y un aislamiento de las causas raíz más rápidos y fáciles. Si encuentra esto aburrido, otros desarrolladores posiblemente menos talentosos o experimentados encontrarán esto no solo aburrido, sino también difícil y tal vez incluso desalentador. Ayúdelos a superar esto mediante la tecnología.
3. Comience a esforzarse por aumentar la calidad del producto: simplifique, modularice, cree marcos de prueba, lidere con el ejemplo, no lloriqueando y amenazando con dejar de fumar.
4. Asegúrese de que los desarrolladores sepan lo que está haciendo, pero también sus gerentes. Un rol de arquitecto tiene mucho más que ver con las relaciones con otras personas que con la codificación y el análisis. Por mucho que odies esto, la política juega un papel clave aquí. Asegurarse de que sus compañeros vean sus logros hace que sea más fácil convencerlos más tarde de que tiene razón. Si aún no está allí, respalde sus afirmaciones mediante investigaciones y POC.
5. Si todo lo demás falla, y solo después de pasar tiempo para intentar mejorar las cosas, hable con su gerente. Digamos que sus habilidades se utilizan mejor en las fases de planificación y diseño y vea qué se puede hacer para cambiar la situación actual. Su producto podría estar en apuros y la respuesta de su gerente podría ser "lo necesitamos para esto aquí y ahora". Sin embargo, insistiría en un plan a largo plazo: ¿cómo vamos a cambiar la situación actual?

Veo el papel de un arquitecto como un privilegio. Puede influir en el producto de una manera que no muchas otras personas pueden, el único teóricamente más influyente que usted es el gerente de I + D del producto (y, posiblemente, el marketing), pero es muy ocupado en la gestión.

El papel de un arquitecto de software tradicionalmente no los tiene arreglando errores. Los arquitectos de software ayudan a solucionar problemas de diseño en el software, por lo que si por error te refieres a la forma central en que se diseñó el software se presta a una mayor fragilidad o dificultad para expandir / mantener, entonces sería el trabajo de las SA proponer o rediseñar aspectos de software para resolver ese problema.

Dado lo que dijiste:

El 50% de mi tiempo lo pasé en Notepad ++ analizando los registros del software e intentando descubrir qué salió mal. El 30% corrige los errores de otros y el resto (si lo hay) revisa el código de espagueti de los desarrolladores.

Ese no es el papel de una verdadera SA y, en cambio, es más de lo que quisiera que nuestros programadores de nivel de desarrollador 1 y desarrollador 2 comiencen junto con un desarrollador senior. Digo eso en particular porque encuentro que realmente ayuda a los nuevos desarrolladores de nuestra compañía a ingresar al producto y al código al trabajar a ese nivel en cuestiones de calidad del código. ¿Eres un nuevo SA en tu empresa y te están pidiendo que hagas este trabajo para ingresar al sistema? Si es así, tal vez eso esté bien por un corto tiempo. Si este es su trabajo diario y lo ha sido por más de un año, entonces posiblemente sea hora de buscar otro rol.

Entiendo tu frustración, pero entiendo que si escribiste el código o fuiste el último en tocarlo, el tiempo es corto y pueden contactarte, muchos gerentes van a acudir a ti para arreglarlo, independientemente de tu título.

Suponiendo que todavía tiene amigos en el grupo de desarrollo que está en crisis, ayudará. El problema es cuando ellos, y lo que es más importante, su administración se acostumbra a ayudarlo, siguen regresando. Como dice "ninguna buena acción queda impune". Si pueden contar con usted para solucionar los problemas, independientemente de su título, usted es solo otro desarrollador y alguien más que pueden usar.

Es un problema difícil de resolver, pero mi consejo es:

1. Solicite el número de cargo para el proyecto este tiempo de proyecto sin arquitecto de software. Creo que los gerentes de proyecto no están tan ansiosos por pedir su tiempo, si tienen que rendir cuentas por ello.

2. Hable con su gerente sobre cuánto tiempo se pierde y con qué grupos o proyectos. Es posible que su gerente le diga que no los ayude y que se concentre en sus proyectos. Si es así, entonces el otro grupo viene y pide ayuda, diles que tu jefe también dijo que no.

3. Organice su trabajo, mantenga claras sus prioridades y no sea tan receptivo a sus proyectos de arquitectura externos.

4. Actúa como un arquitecto, haz que tus compañeros te vean como arquitecto, no como el mismo desarrollador que has sido durante todos estos años. Has dejado a otros del hábito de tratarte solo como desarrollador.

Buena suerte.

No, estás aquí para gestionar el panorama general.

Tiene un problema de administración: corregir errores y mejorar la calidad del código es tarea de los desarrolladores, como arquitecto debe emitir pautas y arquitectura real (UML o lo que sea que haga flotar su barco), luego realizar revisiones periódicas del código para garantizar que estas pautas se sigan correctamente .

Sin embargo, puede implementar y corregir errores en la arquitectura central.

Ejemplo: trabajaría en PRISM, MEF, etc. en un proyecto WPF / C #, pero no trabajaría en XAML para mostrar la pantalla de presentación.

Trabajaría en el diseño de DB pero no escribiría procedimientos almacenados para operaciones CRUD.

etc.

Parte de la respuesta sería encontrar un ingeniero que esté dispuesto a asumir esta carga.

Por supuesto, la razón por la que esto es un problema es que considera que este trabajo no es deseable, lo que no envía el mensaje de que sea atractivo para los otros ingenieros, por lo que tampoco están ansiosos por retomarlo.

Veo dos posibilidades.

1. Se le otorgó el puesto de arquitecto para poder trabajar en elementos de imagen más grandes.
   En este caso, debe mencionar a la gerencia que no puede trabajar en estos elementos de imagen más grandes porque nadie ha dado un paso adelante para asumir el rol de soporte de nivel inferior. Ese es entonces su problema a resolver.

2. El título es en gran parte ceremonial: un hueso arrojado a ti para mantenerte cerca.

En este caso, la gerencia puede no estar terriblemente interesada en aliviar su carga de soporte.

-

Una cosa que definitivamente no será útil para su objetivo es adoptar una actitud de desprecio por los otros desarrolladores e ingenieros que veo filtrarse en su pregunta. Desea que estas personas den un paso al frente y manejen con confianza estos problemas para que no tenga que hacerlo (posiblemente cometiendo algunos errores en el camino). Si saben que simplemente hablarás mal de sus soluciones y las arreglarás después, probablemente nunca darán un paso adelante.

El 50% de mi tiempo lo pasé en Notepad ++ analizando los registros del software e intentando descubrir qué salió mal. El 30% corrige los errores de otros y el resto (si lo hay) revisa el código de espagueti de los desarrolladores.

Este es definitivamente un tipo de trabajo que NO se supone que debe hacer, para este papel. Según mi experiencia / observaciones, el arquitecto debe participar en el diseño de la aplicación, las mejoras, las aclaraciones de los requisitos técnicos y los posibles problemas de rendimiento (no verifica los registros todos los días, pero analiza principalmente los problemas / errores graves) que deben abordarse o evitarse.

En otras palabras, mi punto # 1 es: los arquitectos son los diseñadores e integradores de sistemas de alto nivel con experiencia práctica sobre cómo funcionan / aplican los procesos internos de la tecnología y cómo deben usarse.

Si tiene la oportunidad de asignar y administrar la calidad del código, entonces sus habilidades de administración del trabajo deben mejorarse. Por lo tanto, la planificación del trabajo debe ser su prioridad en el enfoque de "cómo hacer el trabajo".

Punto # 2 : si usted es uno de los pocos desarrolladores en estas aplicaciones, entonces este título es solo otro glaseado de azúcar de la gerencia de la compañía para mantenerlo en el mismo rol de "arreglarlo" con un nuevo título elegante .

El papel de un arquitecto de software es mucho más de lo que está haciendo en su empresa actual. Es responsable de definir estándares de diseño de software, hacer diseños de alto nivel, estándares de codificación, etc. Pero como ha dicho, está trabajando en un producto, lo que significa que, como arquitecto de software, la expectativa de usted sobre la confiabilidad del producto será bastante alta y, en tal caso, su participación en tales cosas no solo ayuda al producto pero también a la empresa, ya que tienes bastante experiencia en eso. Pero también debe contar con cierta exposición al desarrollo de nuevas funciones y nuevas tareas, que inculcarán su interés en su organización actual.

Como arquitecto de software, ¿debo centrarme tanto en analizar los registros y corregir los errores de otros?

En cuestión de hablar, 'Sí'.

Así es como calificaría mi respuesta:

1. De forma predeterminada, debe permitir que los desarrolladores de software analicen los registros y corrijan los errores.
2. Sin embargo ... Usted debe ser consciente de los defectos que se incurrió en una pérdida de datos, requieren una base de datos de rollback onerosa, tomar un largo tiempo para los desarrolladores para resolver, o exigir una disculpa al cliente.
   1. Como regla general, sus informes directos deben informarle sobre tales defectos.
   2. Debe crear una cultura en la que sus informes directos se sientan facultados para informarle sobre tales defectos, pero no obligados a informarle sobre los triviales.

Más sobre el # 2:

1. Estos tipos de defectos generalmente implican una falla arquitectónica. Cuando lo hacen, debe comprender la naturaleza precisa del defecto y diseñar una solución.
   1. Por lo tanto, por extensión, debe estar listo, dispuesto y capaz de examinar los registros y corregir los errores de otras personas (incluso si no confirma directamente el código en el repositorio de código fuente).

La respuesta es probablemente no. ¿Por qué pasa tanto tiempo depurando y problemas de soporte? ¿Alguien te está asignando ese trabajo?

Parece que necesita aclarar lo que debería estar haciendo. Es posible que deba corregir errores; probablemente no sea la mayor parte de tu tiempo.