¿Cómo puedo convencer a mi jefe de que ANSI C es inadecuado para nuestro nuevo proyecto? [cerrado]

Hace unos meses, comenzamos a desarrollar una aplicación para controlar un equipo de prueba desarrollado internamente y registrar un conjunto de mediciones. Debería tener una interfaz de usuario simple y probablemente requeriría subprocesos debido a la grabación continua que debe llevarse a cabo. Esta aplicación se utilizará durante algunos años y será mantenida por varios estudiantes de informática durante este período.

Nuestro jefe se graduó hace unos 30 años (no debe ser tomado como un delito; también tengo más de la mitad de ese tiempo en mi espalda) y ha ordenado que desarrollemos esta aplicación en ANSI C. La razón es que él es el único que estará alrededor todo el tiempo y, por lo tanto, debe ser capaz de entender lo que estamos haciendo. También dictaminó que no deberíamos utilizar tipos de datos abstractos; Incluso nos dio una lista con el nombre de las variables globales (suspiro) que quiere que usemos.

En realidad probé ese enfoque durante un tiempo, pero realmente me estaba ralentizando para asegurarme de que todas las operaciones de puntero fueran seguras y que todas las cadenas tuvieran el tamaño correcto. Además, el número de líneas de código que realmente se relacionó con el problema en cuestión era solo una pequeña fracción de nuestra base de código. Después de unos días, deseché todo y comencé de nuevo con C #. Nuestro jefe ya ha visto el programa en ejecución y le gusta cómo funciona, pero no sabe que está escrito en otro idioma.

La próxima semana los dos nos reuniremos para repasar el código fuente, para que él "sepa cómo mantenerlo". Estoy un poco asustado, y me gustaría saber de ustedes qué argumentos podría usar para apoyar mi decisión.

Cobarde tuyo,

Tenga en cuenta que el "Por favor hágalo así, así que estoy seguro de que puedo mantenerlo" es en realidad un requisito muy bueno: la mayoría de los programas pasan mucho más tiempo manteniéndose que escritos y mantener una solución en una tecnología conocida suele ser una buena idea.

Imagínense si un chico nuevo de la computadora, cuando se le pidió que escribiera una aplicación C #, la escribió en Haskell en dos días y dijo "Oye, funciona y me voy, adiós", dejándote el mantenimiento.

Imagínense si un chico nuevo de la computadora, cuando se le pidió que escribiera una aplicación ANSI C hace 15 años, la escribió en Visual Basic 6 en dos días y la dejó. Ahora debe mantenerlo y Windows 7 comienza a quejarse cuando se inserta el medio de instalación .

Esta podría ser una buena oportunidad para decir, como lo insinuó Heinzi en los comentarios, que "este es un prototipo rápido escrito en C # que se parece mucho a C: ¿debemos prepararlo para la producción o volver a implementarlo en ANSI C como usted? preguntó ", y luego toma la discusión ahora. Tener una fuente real para ver, es mucho mejor que "Oye, ¿no deberíamos escribir nuestra próxima aplicación en Haskell porque es más rápida".

En otras palabras, ahora tiene la oportunidad de demostrar que podría considerarse una nueva plataforma. Mencione que escribió un prototipo antes de la revisión del código; esto ayudará a eliminar la impresión de que está intentando infiltrar C # debajo del radar. Sugeriría que también demuestre que todo el código existente escrito en ANSI C se puede usar desde C #. Personalmente, creo que le dirán que el objetivo sigue siendo ANSI C para permanecer en una sola plataforma.

En este caso, su jefe parecería ser su cliente, y su requisito principal es que pueda mantener la aplicación cuando continúe. Esto parece bastante razonable.

Por lo tanto, la opción es hacer lo que le pida o demostrar que puede completar el desarrollo Y enseñarle cómo mantener una aplicación C # dentro de las limitaciones de tiempo y a un costo menor. Si no puede hacer eso, no está cumpliendo con los requisitos del proyecto.

No ha proporcionado mucha información, pero creo que C es la opción correcta: trabajo como ingeniero en una planta industrial y la mayoría (si no todo) de nuestro código está escrito en C. Si necesita obtener mediciones de un dispositivo (supongo que un medidor de flujo o termopar o similar aquí) y mostrarlo casi en tiempo real C es una excelente opción.

Es rápido, portátil (nunca he escrito en C #, pero no creo que funcione sin una versión particular del marco instalado y, por lo general, solo está basado en Windows).

Por supuesto, podría usar otro idioma para hacer la GUI. Pero podría ahorrarse el esfuerzo y simplemente usar un paquete de tendencias preexistente (hay algunos buenos de código abierto disponibles).

Para resumir, diría que la interfaz subyacente con la parte de hardware C es una buena elección.

Oh querido. Esta es una aplicación en tiempo real? ¿Equipo de control en tiempo real? ¿Recopilando datos en tiempo real? ¿Usando un lenguaje con un recolector de basura? Oh querido.

Si bien estoy de acuerdo en que probablemente puedas hacer la aplicación en un idioma más moderno en menos tiempo, probablemente ese no sea el criterio principal. LA FACILIDAD DE SU PROGRAMACIÓN ES PROBABLEMENTE MENOS IMPORTANTE QUE LOS OTROS CRITERIOS, como los que estableció su jefe, el tiempo de respuesta y el comportamiento determinista.

Te habría sugerido que hagas un prototipo en C # o Python, solo para probar la funcionalidad principal y la interfaz de usuario. ENTONCES, pruebe el rendimiento, midiendo las latencias reales y los tiempos de respuesta, cuando la aplicación recibe muchos datos, durante muchos días de funcionamiento continuo. Lo más probable es que la aplicación podría terminar siendo demasiado lenta o quedarse atrás en momentos aleatorios, cuando VM o el recolector de basura se activa.

Le sugiero que presente lo que ha hecho como PROTOTIPO.

La codificación en C no es tan difícil. Si no estás preparado, dilo. Hay muchos de nosotros listos para el desafío. (He estado haciendo codificación C en tiempo real por, argh, décadas).

Bueno, lo primero que debes hacer es ir a tu jefe y confesar. No ha tenido en cuenta su solicitud clara, y lo peor es que lo ha estado haciendo durante meses. No sé cuánto tiempo tienes en esto, pero suponiendo que es la mayor parte del tiempo asignado para completar el proyecto, tienes que enfrentar el hecho de que pronto estarás buscando un nuevo trabajo.

Cuanto antes lidies con esto, mejor.

En segundo lugar, no creo que pueda convencerlo de que ANSI C es inadecuado, lo que debe hacer es convencerlo de varias otras cosas (1) que c # es adecuado, (2) puede aprender fácilmente a mantener c #, (3 ) que no fue suficiente para escribirlo en C. Suponiendo que todavía tiene un trabajo y un papel que desempeñar en este proyecto, me concentraría en 2, haciendo hincapié en las similitudes entre c y c #.

Citas en respuesta a comentarios ...

Hace unos meses, comenzamos a desarrollar una aplicación [...] Después de unos días, descarté todo y comencé de nuevo con C #

ha ordenado que desarrollemos esta aplicación en ANSI C. La razón es que él es el único que estará presente todo el tiempo y, por lo tanto, debe ser capaz de comprender lo que estamos haciendo.

Este es un requisito bastante razonable.

También dictaminó que no deberíamos utilizar tipos de datos abstractos;

Esto no tiene sentido. Ahora está comenzando a oler un poco sospechoso, porque este es un requisito de diseño del programa y no un requisito de idioma. Si el código fuera fácil de mantener, la implementación de ADT o el uso de los bien probados y preexistentes deberían ser una prioridad.

Incluso nos dio una lista con el nombre de las variables globales (suspiro) que quiere que usemos.

Ok, ahora apesta. Ahora podemos decir que su jefe tiene una experiencia limitada no solo de varios lenguajes de programación, sino también de la programación en general. Un programador veterano experto, sin importar la preferencia de idioma, nunca haría tal declaración. (La única excepción que se me ocurre es si la mayor parte del código está destinado a ejecutarse en un sistema incrustado bastante pequeño, y por lo tanto se esperaba que toda la memoria de trabajo necesaria para el código fuera asignada previamente. La idea de que el mismo código se espera que tenga un nivel de pantalla que la UI argumenta en contra de que ese sea el caso, sin embargo).

Supongo que su jefe nunca ha estado involucrado en proyectos de software a gran escala y de misión crítica, pero es más probable que haya estado flotando en varios proyectos de baja calidad.

Por lo tanto, esto no tiene nada que ver con el lenguaje de programación C. También puede escribir fácilmente programas igualmente repugnantes en C #. Es un error muy común creer que el buen diseño del programa depende del idioma. ¡Eso simplemente no es cierto!

C # ciertamente tiene una sintaxis más bonita, más limpia y menos oscura que C. Tiene una gran cantidad de soporte de diseño de programas, ya que tiene muchas más palabras clave relacionadas con OO que C. Pero aparte de eso, no le dice cómo escribir sus programas. Si cree que todo lo escrito en C es horrible por defecto y todo lo escrito en C # es el paraíso por defecto, apuesto a que actualmente está escribiendo programas de C # bastante horribles sin darse cuenta.

Lo que sugeriría es que haga un diseño de programa abstracto, independiente del lenguaje, pero detallado antes que nada. Use el enfoque normal orientado a objetos. Qué objetos hay y cómo se comunican entre sí, cuáles son las dependencias necesarias, etc. Cuando le ha dado suficiente importancia al diseño del programa y lo ha escrito en papel, no debería importarle mucho a usted ni a su jefe. idioma en el que elegiste implementarlo.

El primer problema que debe abordar es emocional e irracional. La industria de TI está en constante cambio y, aunque hay lugares para todo, negarse a mejorar o aceptar el cambio es un problema.

¿Por qué su jefe se aferra a ANSI C? Si ese es el único idioma que él o ella conoce, entonces tal vez sea hora de un cambio, pero un argumento racional puede ser insuficiente. ¿Se sentirá infravalorado o posiblemente despedido si se ve obligado a trabajar en un idioma desconocido? Haga hincapié en la experiencia que tiene y otros beneficios que aporta.

Si no resuelve este problema, se desperdiciarán todos los argumentos racionales que pueda aportar. Como subordinado, es posible que no seas el que pueda tener esta discusión con él. Quizás mencione este tema a uno de los otros gerentes, si hay alguno.

También considérelo desde su perspectiva. ¿Por qué quieres usar C #? ¿Cuánto de esto es el deseo de usar algo nuevo y genial? Se honesto contigo mismo. Si reconoce esto, le ayudará a discutir más eficazmente.

La segunda cuestión es de riesgo y costo. Escribir software es costoso y la elección del idioma es un factor importante en eso. Considerar:

1. ¿Cuánto tiempo tomará escribir en C # versus C? Con una orientación de objeto más fácil y una mejor recolección de basura, C # puede ser más fácil. Sin embargo, si la aplicación usa muchas llamadas API no administradas, C puede ser más fácil.
2. Si usa C #, ¿necesita comprar herramientas adicionales? Parece que ya usa Visual Studio, pero ¿necesita herramientas adicionales para la localización, revisión y análisis de código, depuración, etc.?
3. ¿Qué tan fácil es de mantener? Si encuentra un error, qué tan rápido se puede solucionar. C # puede reducir la orientación de este objeto. La recolección automática de basura también evita la mayoría de los problemas de pérdida de memoria y puntero.
4. ¿Qué tan fácil es apoyar? Si tiene personal de soporte, pueden saber cómo leer un volcado de memoria, pero ¿saben cómo usar windbg con SOS? ¿Las máquinas de destino ya tienen instalada una versión adecuada del marco .Net?
5. Considere la dotación de personal. ¿Cuántas personas conocen C versus C #? Si uno o ambos abandonaron la organización, ¿qué tan fácil sería reemplazarlo? ¿Los desarrolladores de C son más baratos o más caros que los desarrolladores de C #?

Podría continuar, pero el punto es dejar de discutir solo sobre los méritos técnicos de los idiomas. Los méritos técnicos son cosas que solo usted y su jefe entienden. Si comienza a hablar sobre el impacto comercial, atrae a un grupo mucho más amplio de personas y presenta un argumento mucho más convincente.

Quizás C es una mejor opción. C # no es automáticamente mejor para todas las situaciones. Tal vez haga este proyecto usando C, pero haga una prueba de concepto de C # para el próximo. Recuerda que puedes perder la batalla pero aún así ganar la guerra también.

Quizás otro argumento: probablemente sea muy difícil encontrar estudiantes de ciencias de la computación que tengan suficiente experiencia para escribir código C sin cometer errores. ANSI C no es lo primero que la gente aprende hoy.

Ahora todos los estudiantes de informática me matarán.

No ha logrado convencernos por completo de que ANSI C era inadecuado. C es un lenguaje excelente que parece adaptado para el tipo de tareas que ha descrito. Con la breve descripción de la tarea (excepto el requisito de lenguaje), también recomendaría C (o tal vez ir).

Creo que el problema es que estabas programando en C con tu mente pensando en C #. Tengo un problema similar cuando cambio de Perl a C o Java. Debes aprender a adaptarte al idioma y no aprender a traducir desde tu forma de pensar hacia el idioma del día.

El problema no es tu jefe o el lenguaje C, el problema es abrir tu mente hacia diferentes formas de pensar. Cambiar el lenguaje de programación es algo que lo beneficiará.

Primero, debes decirle a tu jefe que ahora está en un idioma diferente. Él estará (comprensiblemente) enojado si traes algo intencionalmente en contra de los requisitos sin previo aviso.

Ahora, la mejor manera de explicar estas cosas a los jefes / gerentes es expresarlo en términos de tiempo y dinero. Calcule cuánto tiempo tomaría un proyecto de este tipo en ANSI C, y luego calcule cuánto tiempo tomaría en un nivel superior, como C #. Tenga en cuenta que dije de nivel superior, no moderno. Esto también puede ayudar a suavizar las cosas. Quiero decir, no abordarías pintar una habitación con solo un pequeño pincel, usarías rodillos y otras cosas que hacen que cada trazo (línea de código) cubra más área del proyecto. Además, si usted o uno de los miembros de su equipo no conocen C, o se sienten cómodos haciendo un gran proyecto en C, esto afecta aún más el problema del tiempo porque tendrán que ponerse al día.

También parece que tu jefe está tratando de microgestión. Estoy seguro de que una de las otras respuestas tratará de explicar cómo hacer que tu jefe lo haga menos

La aversión del supervisor a los ADT se abordó en otra parte, al igual que la aparente inconsciencia del desarrollador de los costos de GC, por lo que me centraré en los "hilos".

Quizás, en lugar de pensar en términos de subprocesos .NET (o JVM, si está tan adoctrinado), lo que puede desear son múltiples procesos, utilizando algún mecanismo de comunicación entre procesos (IPC) para comunicarse entre ellos. Por ejemplo: mensajes de Windows, memoria compartida, memoria intermedia de archivo asignada a memoria, canalización con nombre, lo que sea. Dedique pequeños procesos a interactuar con un dispositivo o aspecto del dispositivo y verifique el IPC para comunicar actualizaciones y reconocer solicitudes, y tenga un proceso algo mayor para mantener la GUI y comunicarse con los "monitores" del equipo utilizando cualquier IPC que seleccione.