¿Debería un desarrollador argumentar en contra de características innecesarias o dañinas?

¿Cuál es una buena actitud de los desarrolladores cuando discuten nuevas características, y a saber, características no críticas / cuestionables?

Digamos que está desarrollando algún tipo de lenguaje similar a Java, y el jefe dice: "¡Necesitamos punteros para que los desarrolladores puedan jugar con la memoria de objetos directamente!"

¿Debería el desarrollador derribar la idea porque agrega una complejidad inimaginable y vulnerabilidades de seguridad, o debería hacer lo que se le pide?

Puede que este no sea un buen ejemplo, pero ¿qué pasa con las cosas que están más en un área gris, como agregar botones que interrumpen el flujo de trabajo o van en contra de la estructura interna del programa, etc.?

¿Cuál es la distribución óptima de "puede hacer" versus "no puede hacer" para un programador regular?

EDITAR: La pregunta no es sobre un mal jefe: D

Estaba más interesado en cómo las personas abordan los nuevos problemas que agregan una cantidad notable de problemas, mientras que tal vez son marginalmente útiles.

¿Debería ser la actitud general:

1. si lo haremos, joder la complejidad
2. tal vez
3. no, el retrabajo general y las implicaciones no justifican el cambio

¿Cuál debería ser la reacción de un buen desarrollador?

Lo mejor es tener una reunión y exponer los pros y los contras como un grupo, y en base a eso discutir la mejor solución. Si tienes un equipo, haz que acuerden una solución. Una vez que un equipo está de acuerdo en algo, los gerentes y "jefes" tienden a ir con la solución.

Si su jefe aún no está de acuerdo, entonces ha hecho todo lo que puede hacer: ha reunido a su equipo y gerentes y ha cubierto los pros y los contras y, a pesar de eso, su jefe eligió una solución potencialmente inferior.

La clave para esto es discutir los pros y los contras como grupo. Al hacerlo, está discutiendo cuál es la mejor solución con su equipo, y al mismo tiempo está señalando la decisión de su jefe (antes de que él la tome) sin la reacción política de dar la vuelta después del hecho de decirle a la gente por qué cree que la decisión de su jefe fue el equivocado.

Esta es una situación delicada que involucra políticas laborales, pero se puede manejar de manera amigable.

Si tu jefe te dice que hagas tareas estúpidas, entonces deberías (amablemente) explicar por qué es estúpido.

Si él o ella no entiende el punto, entonces usted está obligado a hacer cosas estúpidas. Eso es. El es el jefe. En tal caso, puede hacer lo que él / ella le diga, o hablar con su jefe o cambiar el trabajo.

Podría decirle al jefe que, si bien es técnicamente posible, le costará X cantidad de tiempo y dinero gastado en el esfuerzo de análisis, diseño, reescribir el código existente, pruebas, pruebas de regresión, ... Y luego preguntar si la característica vale la pena. . A veces la respuesta será "¡sí! ¡Debemos tener esto!", A veces será "no, supongo que no".

Si la función que se solicita viola algún principio básico de la aplicación (como "¡Agregar un botón azul!" A una interfaz de usuario especificada y diseñada para tener solo botones rojos según la solicitud del cliente), creo que está bien preguntar "¿Por qué?" y mencionar que va en contra del diseño preestablecido.

Al final, casi todo es un "poder hacer" (puede que no sea difícil desde un punto de vista técnico agregar un botón rojo a una interfaz de usuario solo azul), es más una cuestión de "¿debería hacerlo?"

Para responder a su pregunta editada, creo que la respuesta debería ser # 2, "Quizás", a la espera de una mayor investigación y análisis.

No desea responder # 1 "Sí, incondicionalmente" porque podría quedarse atascado comprometiéndose con algo que no es capaz de entregar en el plazo establecido.

No querrá responder el n. ° 3 "No, es demasiado trabajo" porque parece que no está cooperando y es innecesariamente difícil.

Desde la perspectiva de un desarrollador: NUNCA le digas a nadie que paga las facturas que no pueden tener lo que quieren. En cambio, puede decirles que no pueden tenerlo por ese precio, o que no pueden tenerlo exactamente como lo concibieron originalmente.

A su ejemplo de "puntero"; .NET, un entorno de código administrado, tiene punteros. Son críticamente necesarios para mucha interoperabilidad con código no administrado. Sin embargo, su uso "seguro" está estrictamente regulado, y si se usa en código "inseguro", ese código requiere mayores permisos de seguridad en el tiempo de ejecución. Si estaba desarrollando un lenguaje administrado que también requería acceso directo a la memoria a través de punteros, podría idear un esquema similar de clasificación detrás de escena donde pudiera, utilizando punteros administrados de solo lectura donde no podía calcular automáticamente y permitiendo " verdadero "punteros solo en las áreas más confiables de la base de código.

Para sus ejemplos de GUI: si sabe que una nueva característica "romperá" el flujo actual de código, puede probarlo y desarrollarlo de manera más sólida para revertir cualquier trabajo anterior realizado por el flujo de trabajo. Sus clientes, y algunas veces incluso su gerente, generalmente no tienen idea ni interés en la estructura del programa; si algo que quieren es difícil debido a la forma en que estructuraste el programa, entonces, por definición, la estructura es incorrecta porque no te permite hacer lo que el cliente quiere.

En todos los casos, esta nueva característica puede aumentar el alcance del trabajo requerido más allá de lo que el cliente había pensado que sería. Eso a su vez requerirá una extensión del cronograma, más dinero y / o una reducción de otro trabajo planificado.

Sin embargo, si conoce una forma de lograr el mismo resultado básico de una manera más fácil o más lógica, entonces eso se puede sugerir al cliente. Aunque definitivamente existen, afortunadamente aún no he visto a un cliente que se negó categóricamente a escuchar los comentarios de los desarrolladores, especialmente en un entorno ágil donde hay un "propietario del producto" cuyo único trabajo es relacionarse con el desarrollo en varios detalles necesarios, como estas.

Si pasas muchos años programando para aplicaciones grandes y piensas críticamente al respecto, desarrollarás una sensación finamente ajustada de cuándo una característica causará problemas que superen su utilidad. Otra palabra para esto es sabiduría , y tal como es el caso con otros tipos de sabiduría, puede ser un desafío hacer que aquellos sin ella vean su valor.

Otros carteles han argumentado que debe tratar de cuantificar el costo del problema que será introducido por una característica problemática, y esa es una buena idea cuando es posible, pero generalmente no lo es. Por lo general, solo es posible estimar los costos de implementación inmediata. Incluso eso a menudo es difícil para características más grandes. En cuanto a los costos futuros, estás en una situación difícil. No sabe con certeza qué otras características serán necesarias o cuánto tiempo estará en mantenimiento el producto. El costo generalmente será mucho más alto de lo que podría respaldar con una estimación basada en hechos concretos.

Cuanta más competencia haya demostrado en el pasado, más margen de maniobra tendrá para declarar una característica como una mala idea. Eso solo puede llegar con el tiempo y un historial demostrado de éxito. Dicho esto, siempre debe expresar entusiasmo por cumplir con la solicitud, ya que es lo que su cliente desea. Debe expresar sus reservas en función de su experiencia, y una vez que lo haya hecho, se convierte en un problema en el 90% de los casos porque comenzará una conversación que llega a la raíz del problema, que es: ¿Por qué le han pedido que agregue? esta característica en primer lugar? En ese momento, puede ofrecer alternativas, o tal vez aceptar que, aunque la función solicitada presentará problemas, todavía es necesaria.

Por supuesto, también es posible que estés equivocado. ¿No es divertida la ingeniería de software?

Como la pregunta es bastante vaga, voy a generalizar un poco con mi respuesta.

Siempre pregúntales, pero escucha su razonamiento. A veces, las personas simplemente se olvidan de la practicidad de una función o cuánto tiempo llevaría la programación. Por otro lado, a veces nos vemos atrapados en una mentalidad de programador de ser eficientes / sin lujos / etc. y olvidamos que lo que consideramos no esencial para un proyecto realmente no es para el cliente.

Si tienen una buena razón, dígales cuánto tiempo tomará programarlo y todos los posibles problemas que encontrará durante la implementación y verifique si aún quieren continuar con él. De lo contrario, indique por qué no cree que sea una buena idea y vea cuál es su reacción. Enjuague y repita.

La mayoría ya está dicho, pero hay una cosa que destacaría en mi entorno de trabajo actual. Trabajo para una compañía que es contratista de otras compañías y nuestras aplicaciones están relacionadas con procesos de negocios (a una cantidad justa impulsan las ventas y la comunicación con los clientes).

Los procesos comerciales junto con los productos que lo acompañan pueden ser (al menos si la empresa es lo suficientemente grande) muy complejos. Hasta cierto punto, si está modelando algo complejo, la aplicación resultante tendrá una complejidad relativa. Como la mayoría de las personas de negocios solo ven su parte del proceso, la aplicación / proceso completo se basa en una mayor complejidad que lo que es visible para un solo usuario.

Mi punto es que cuando surge un nuevo requisito comercial, funcionará para la gente de negocios, porque no aumenta la complejidad mucho más, pero puede tener un mayor impacto en todo el sistema. En mi opinión, esta no es una razón para argumentar en contra de ese cambio. Es el punto correcto para discutir los esfuerzos (y los gastos) con el cliente. Probablemente no evitará que el cliente tenga esa característica desarrollada, pero con el tiempo se familiarizarán con las aplicaciones y algunas discusiones sobre "¡uuh, eres tan caro!" Será mucho menos exigente.

No sé si se encuentra en una situación comparable, pero he aprendido que la situación de las partes interesadas no necesariamente tiene la misma complejidad inminente como la que enfrentan los desarrolladores y arquitectos del sistema de TI. En esa situación, la comunicación ayuda a ambas partes.

Disculpe, pero esta pregunta suena como un menor pidiendo consejo paternal. Si este es el caso, el buen desarrollador deberá adoptar estos mandamientos:

• Permanece fiel a ti mismo. Si su intestino se siente incómodo con una característica, exprese sus inquietudes de manera audible. Hay muchas posibilidades de que el equipo esté esperando una apertura.
• No intente sustituir la experiencia con las reglas generales de los experimentados. Para usted, cada situación es diferente, cada característica es nueva. Esta es una ventaja que sus mayores no tienen.
• El desarrollo de software no es ciencia exacta, nunca lo será. Por lo tanto, acumula sabiduría, no comportamiento.
• Acepta la derrota. Si el equipo acuerda lo contrario, no repita sus preocupaciones hasta la saciedad.
• Piensa positivo. Si la idea realmente está pidiendo 'derribarla', intente encontrar y nombrar aspectos positivos antes de enumerar sus deficiencias.
• Aprende a interactuar con las personas. Los desarrolladores a menudo colocamos el conocimiento técnico sobre la competencia social. Las habilidades técnicas alcanzan su punto máximo temprano en la vida, pero la competencia social puede seguir creciendo hasta la jubilación.

Creo en rechazar los malos requisitos. Pero también creo que cuando has dado tu mejor oportunidad para explicar por qué son malos y todavía los quieren, entonces estás de acuerdo y haces tu trabajo.

Por ejemplo, he tenido personas que quieren requisitos que se excluyen mutuamente de algo que la aplicación ya hace. Si hago eso, entonces esto, 100% garantizado, se romperá. Así que les devuelvo el requisito y les digo que esto romperá esta otra regla comercial que ya tenemos establecida y ¿quieren cambiar también esta regla? A menudo, el pequeño grupo que presenta un requisito particular no tiene acceso a una imagen más amplia de lo que puede hacer el resto de la aplicación. La mayoría de las veces, cuando envié uno de estos, el cliente se dio cuenta de que la regla inicial era más crítica y decidió que el cambio que quería no valía la pena. Cuando decidieron hacer el cambio, lo hicieron después de consultar con las personas que impulsaron el requisito inicial.

A veces, solo hacer preguntas de aclaración les hará ver que el problema no es tan simple como pensaban. A veces quieres preguntar por qué quieren algo y llegar a la verdadera necesidad que está impulsando el cambio. Una vez que comprenda eso, a menudo es más fácil ver una solución alternativa que funcione para usted como desarrollador y satisfaga sus necesidades. Si puede presentar esa solución en términos de cómo satisfará mejor sus necesidades que la sugerencia original, habrá mejorado enormemente sus posibilidades de que se acepte su cambio.

A veces, cuando un cambio va a crear estragos en un nivel básico en su diseño, solo darles la nueva estimación de las horas que tomará el cambio es suficiente para desactivarlo. Si combina eso con una evaluación de riesgos que señala en qué funcionalidad crítica podría estar introduciendo nuevos errores al decirles que tomará 6 semanas de esfuerzo dedicado de 3 personas, de repente ya no es tan importante.

Pero a veces les dices que no es una buena idea y por qué, y todavía dicen: "Lástima que la necesitemos". Ganas algo y pierdes algo y, a veces, las necesidades del negocio realmente han cambiado y la aplicación debe adaptarse a eso. Una vez que se ha finalizado la decisión, ya no es el momento de cuestionar lo que está haciendo y el momento de seguir haciéndolo. Si ha documentado sus objeciones, entonces personalmente debería estar en un buen lugar cuando sobrepase el presupuesto y cause errores nuevos y más emocionantes. E incluso podrían estar más dispuestos a escucharte la próxima vez cuando hayas acumulado un historial de estar en lo cierto en este tipo de cosas.

La clave para ganar muchas de estas discusiones (nadie las gana todas) es primero construir un historial para saber de qué está hablando. Luego envíe un documento escrito que indique qué preocupaciones tiene (muchos gerentes son adversos al riesgo, es más probable que no quieran que alguien tenga un documento que demuestre que está equivocado más tarde, por lo que prestan más atención a lo que usted escribe) y finalmente para asegurarse de que entiendan todos los costos (no solo horas, sino también riesgos de seguridad, la introducción de nuevos errores, la falta de plazos, etc.) de realizar el cambio. El cambio no es gratuito y deben entenderlo. La siguiente clave es hacer esto como un adulto y no como un niño quejumbroso ("pero no quiero usar ... porque no me gusta"). Haga un caso de negocios por no hacerlo y obtendrá mucho más lejos para retrasar un mal requisito.

Si te leo correctamente, la verdadera pregunta es sobre la complejidad desconocida. Inicialmente leí tu pregunta como: "Veo el riesgo extremadamente probable de un exceso de complejidad, pero el jefe no", pero estás diciendo que el jefe no es un problema, así que supongo que no estás seguro de cuáles son los riesgos. de agregar complejidad inaceptable son.

En ese caso, recomendaría algún tipo de estrategia de mitigación de riesgos. Imagen que está considerando agregar servicios WCF / web a su API, lo que podría ser increíble o mucha complejidad sin recompensa:

• agregue la característica en una rama. Si funciona, fusionarlo. Si se convierte en un nido de ratas, mátalo.
• inicie un nuevo proyecto de una página y haga una prueba de concepto. Si no puede hacer una prueba de concepto en poco tiempo, suéltela. Si la prueba de concepto funciona, hazla más grande e intégrala con tu
• recorra la web en busca de personas que se preocupan por esa característica o tecnología. Donde hay mucho agarre, una tecnología puede presentar algunos riesgos reales de excesiva complejidad. Java Beans y COM + son probablemente, viejos, pero buenos ejemplos de características que realmente aumentaron la complejidad y pueden o no haber entregado en el lado de los beneficios de la ecuación

Discutir no. Discutir posiblemente sí. Pero debe tratarse como una adición a la especificación y priorizarse con otras características. Si sabe que la solicitud agregará una cantidad razonable de tiempo y complejidad para implementar, entonces indíquelo por adelantado. No como una oposición a la solicitud, sino como una explicación de lo que cree que se necesitará para implementar.

Depende mucho de la solicitud. La implementación del puntero es lo suficientemente grande como para efectuar un proyecto completo, por lo que sus méritos deben sopesarse si se le da una opción.

Implementando un botón que rompe el flujo. Tal vez no sea un gran problema si el formulario se puede diseñar de manera que el botón sea opcional. He hecho esto mismo de hecho. Agregué el botón, pero también recopilé suficiente información de antemano para que el botón se convirtiera en opcional. Los usuarios que esperaban que estuviera allí lo usaron y aquellos que se dieron cuenta de que era simplemente redundante no lo hicieron.

Se trata de equilibrio y saber cuándo elegir tus batallas. Algunas cosas son más fáciles de implementar de todos modos en lugar de tratar con los aspectos sociales de no incluirlo.

El problema que veo es su uso de la palabra argumentar.

Debe mencionar los problemas de diseño y el razonamiento detrás de ellos, pero tenga cuidado porque los programadores tienden a ponerse a la defensiva sobre las posiciones que han tomado y argumentar puntos solo por el argumento (A veces). Tengo que evitar discutir un poco, y no siempre tengo éxito. Además, a medida que envejezco me doy cuenta de que estoy equivocado con más frecuencia de lo que solía ser, o peor aún, no reconocí la frecuencia con la que solía estar equivocado :)

Si tiene requisitos claramente establecidos (el idioma debe ser seguro, necesitamos punteros para acceder a las rutinas heredadas), entonces podría presentar cómo entran en conflicto los dos requisitos y preguntar cuál es más importante. Una vez que tenga los requisitos y las razones detrás de ellos, incluso podrá llegar a una solución completamente diferente que admita ambos requisitos (JNI, más o menos).

Si no es así, ¡quizás sea un buen momento para codificarlos!

1. Date cuenta de que no lo sabes todo y que no puedes hacerlo todo.

2. Si está seguro de que es una mala idea, diga qué es malo.

3. Si intentan presionarlo, diga cualquiera: necesita más tiempo para analizar, si necesita más tiempo o dice que no hemos encontrado una buena solución para este problema.

4. Si todavía insisten en implementar la mala idea, obtenga un reconocimiento de ellos que le haya desaconsejado, incluidas sus razones. Incluso puede enviar un correo electrónico resumiendo la discusión con una copia a su gerente. Esto podría ahorrarle un ** más tarde.

En un escenario ideal, tendría un desarrollador principal que toma las decisiones finales en el aspecto técnico y un líder comercial que toma las decisiones finales en el lado comercial. Esto respondería las dos preguntas principales:

1) ¿Qué? ¿Qué quiere el cliente?

2) ¿Cómo? ¿Cómo logramos esto desde una perspectiva tecnológica?

Lo que el cliente quiere es el máximo responsable de la toma de decisiones, ya que son ellos quienes pagan las facturas.

Como desarrollador, no debería importarle qué requisitos se soliciten para su implementación.

Sin embargo, debe explicar si algo no es realista y si hay mejores formas.

A veces es realmente una solicitud del cliente (proveniente de la política interna del cliente). Entonces es inútil y debe hacerse (pero la gerencia también debe considerar si continúan con ese proyecto o si deben renegociar el precio).

Esto es casi una tarea diaria para mí, y de hecho me alegro de que lo sea.

Si tiene el cambio para dar su opinión sobre si ciertos requisitos deberían o no ser parte de la aplicación, las personas no técnicas esperarán que complete su conocimiento técnico (por ejemplo, "usar punteros haría que la aplicación sea inestable" o "usar un parámetro GET para X es un riesgo de seguridad "). Los técnicos también agradecerían sus comentarios sobre alguna ventaja o desventaja específica en la que quizás no hayan pensado.

Por supuesto, es duro cuando todos quieren la función X y terminas diciendo "puede que no sea bueno", pero al final, todos están tratando de hacer una aplicación segura, robusta y estable (mantenible, flexible, etc.) ) y cada voz debe contar.

En respuesta a su pregunta, no es parte del trabajo de un desarrollador (que es desarrollar), pero es un "extra" que ofrece calidad y trabajo en equipo.

Si está en condiciones de comprender las desventajas de hacerlo (complejidad, falta de usabilidad, etc.), le conviene a todos explicarlo lo mejor que pueda. A menudo, los que no son desarrolladores no entienden los problemas de agregar nuevas funciones. Es fácil para ellos porque no tienen que hacer nada ni siquiera pensar en ello.

Sin embargo, si los poderes fácticos deciden que se agregará la nueva característica, entonces debe hacer el mejor trabajo posible. Es un desafío.

Y, si la nueva característica es demasiado estúpida o el entorno de trabajo es demasiado malo, entonces es hora de encontrar otro trabajo.