Consecuencias de hacer un software "lo suficientemente bueno"

Question

¿Hacer software "lo suficientemente bueno" le permite a usted ser un programador?

Aquí están mis pensamientos sobre esto:

Bueno Joel Spolsky de JoelOnSoftware dice que los programadores se aburre porque hacen "lo suficientemente bueno" (software que satisfaga los requisitos a pesar de que no son tan optimizado). Estoy de acuerdo, porque a la gente le gusta hacer las cosas bien todo el tiempo. A un lado de los espectros, quiero ir tan lejos como:

1. Optimización de software de tal manera que puedo aplicar todos mis conocimientos en Matemáticas y Ciencias de la Computación he adquirido en la universidad tanto como sea posible.
2. Realice todo el proceso de desarrollo de software posible, por ejemplo: obtenga las especificaciones de un repositorio, genere el código, compile, pruebe, implemente con los manuales en un solo paso de compilación automatizado.

Por otro lado, un rasgo para nosotros humanos es que nos gusta la variedad. Para poder mantener la atracción (programación amorosa), tenemos que pasar de un proyecto o tecnología a otro para no aburrirnos y "divertirnos".

Me gustaría conocer su opinión acerca de si hay algún efecto secundario bueno o malo en la realización de un software "lo suficientemente bueno" como programador o ser humano.

Answer 1

Realmente considero que los programadores son lo suficientemente buenos para ser mejores que la variedad azul-cielos-hacen-que-todo-es-perfecta.

Eso es porque, aunque soy codificador, también soy un hombre de negocios y me doy cuenta de que los programas son no para la satisfacción de los programadores, sino para satisfacer una necesidad comercial específica.

De hecho, tuve una discusión en otra pregunta con respecto a la mejor manera de detectar un juego de tres en raya ganado ganado (una pregunta de la entrevista).

La mejor solución que he recibido es de un candidato que simplemente marcó las 8 posibilidades con if declaraciones.Hubo algunos que dieron una solución generalizada que, aunque viable, era totalmente innecesaria ya que las especificaciones eran bastante claras, era solo para una placa de 3x3.

Muchas personas pensaban que estaba siendo demasiado restrictivo y la solución "ganadora" era basura, pero mi opinión es que no es tarea de un programador escribir un software perfectamente extensible. Su trabajo es satisfacer una necesidad comercial.

Si esa necesidad empresarial les permite la libertad de hacer más de lo necesario, está bien, pero la mayoría del software y las soluciones se entregan con limitaciones de tiempo y costo. Los programadores (o cualquier profesión) no trabajan en el vacío.

Answer 2

Como programador, quiero escribir un excelente software sin defectos. No estoy particularmente interesado en dorado, el acto de agregar funciones innecesarias que "mejoran" el software, aunque todos lo hacemos hasta cierto punto. En ese sentido, estoy satisfecho con el software "lo suficientemente bueno", si bien significa que hice lo que me pidió el cliente y, al mismo tiempo, lo diseñé bien y me aseguré de que sea de alta calidad.

Lo que me molesta es cuando tomo atajos y escribo código malo, no probado. Odio escribir código con errores o donde no he podido refactorizarlo en un mejor diseño a medida que avanzaba. Cuando dejo entrar un montón de deudas técnicas (estar demasiado ocupado escribiendo nuevas funciones en lugar de mejorar las funciones antiguas de forma sistemática, ya que estoy agregando nuevas), sé que eventualmente tendré algo que, mientras el cliente esté feliz con eso, no lo seré.

Afortunadamente, en mi lugar de trabajo, la gerencia sabe el valor de mantener el código limpio y sé el valor de no obsesionarse con el objetivo escurridizo de la perfección. Ningún código es perfecto, pero "lo suficientemente bueno" tiene que significar que el código está bien diseñado. Aprendí, y todavía estoy aprendiendo, a estar contento con el código que cumple con los requisitos del cliente y que la mejor característica es la que no necesita implementarse. Afortunadamente, tengo suficiente trabajo para hacer esas funciones de caída porque no son necesarias, es algo bueno.

Answer 3

IMO existe una gran diferencia entre "lo suficientemente bueno" y el código de mierda. Para mí "lo suficientemente bueno" se trata de satisfacer los requisitos (tanto funcionales como no funcionales). Creo que es peligroso para la gente suponer que "lo suficientemente bueno" significa tomar atajos o no optimizar el código. Si los requisitos no funcionales requieren un código optimizado, eso forma parte de mi definición de "lo suficientemente bueno".

Answer 4

La clave de su pregunta es cómo se define "bueno". Para una persona de negocios, el software "bueno" es un software que resuelve las necesidades del negocio. En ese caso, se trata más bien de asegurar que las especificaciones fueron bien entendidas y debidamente implimented. A la persona de negocios puede no importarle si el programa no es tan rápido o eficiente de memoria como podría ser.

Piensa en el software comercial que utilizas, ¿es perfecto? Realmente no conozco a nadie, incluso a mis amigos de Microsoft, que argumentarían que el código en Windows es "perfecto" o algo parecido. Pero es innegable que Windows es (y siempre ha sido) "lo suficientemente bueno" para que millones de personas lo usen a diario.

Este problema se remonta a mucho antes de la programación. Estoy seguro de que has escuchado "Si no está roto, no lo arregles" o el original en francés "Le mieux est l'ennemi du bien". Pudo haber sido Voltaire quien escribió sobre "el bien siendo enemigo de los grandes".

y considerar lo que sucedería si los responsables de contratación decidieron dejar de contratar programadores "buenas" y ha insistido en que cada solicitante tuvo un promedio de 4.0 en la universidad perfecta, por mi parte, nunca habría conseguido un trabajo como programador ;-)

Por lo tanto, para mí es un caso de hacer lo mejor que se puede dado el tiempo y las limitaciones presupuestarias. Con más tiempo y más dinero, siempre podría hacerlo mejor.

Answer 5

"Lo suficientemente bueno" está en el ojo del espectador. Con demasiada frecuencia, "lo suficientemente bueno" es el refugio de personas incompetentes que escriben algo que crea la impresión de satisfacer los requisitos de un trabajo. Mi "lo suficientemente bueno" es poco probable que sea lo mismo que su "lo suficientemente bueno".

En última instancia, todo lo que hacemos debe implicar concesiones. Algunas personas harán las concesiones incorrectas y entregarán software malo y algunas personas harán las concesiones incorrectas y no entregarán. Raros son los que pueden hacer las compensaciones correctas y entregar software que realmente es lo suficientemente bueno.

Answer 6

Depende de lo que quiere decir con "lo suficientemente bueno". Puedo ver un cierto riesgo en el nivel de diseño, si lo haces lo suficientemente bueno, puede que resulte doloroso mantener y extender tu aplicación.

Answer 7

Hay por lo menos dos aspectos de la calidad que tenemos que tener en cuenta: la calidad del software

• : ¿el software cumple con los objetivos/requisitos deseados? ¿Entregamos construcciones que tienen errores críticos? ¿es fácil para los usuarios finales operar?
• calidad de código: ¿qué tan difícil es mantener el código? ¿Es fácil implementar nuevas características?

Si está creando un software productivo, creo que es bueno suponer que nunca es lo suficientemente bueno en ambos aspectos. Cada pequeña característica cuenta y si los usuarios no encontrarán lo que necesitan o si el producto no es lo suficientemente estable, echarán un vistazo a la competencia. También desea implementar nuevas características lo más rápido posible, para que tenga una ventaja competitiva en el mercado.

La situación es interesante si está creando software empresarial personalizado, donde los usuarios finales y los que toman las decisiones generalmente no son las mismas personas, entonces las características/calidad/dinero se convierten en parte del proceso de negociación. Lo que solemos hacer es poner una restricción "lo suficientemente buena" en estos tres aspectos: tenemos un conjunto de requisitos que cumplir, una calidad que mantener y, por lo general, no el tiempo suficiente para mantener ambos.

Lo que generalmente se olvida en este proceso es el segundo punto: calidad del código o mantenibilidad. Nosotros, los programadores, entendemos que el código malo o tardío se tomará su revancha y resultará en errores críticos o costos de mantenimiento. Los que toman decisiones no. El problema es que la responsabilidad y los riesgos son asumidos por usted (su empresa, su división, etc.) y será el primero en culpar si algo sale mal.

Mi opinión es: para la calidad del software haga lo que el cliente le diga que haga, ellos sabrán mejor qué características son críticas para ellos, cuántos errores puede tener el software, etc. Para la calidad del código y facilidad de mantenimiento: haga lo mejor que usted puede, aprender a hacer más y enseñar a otros a hacer lo mismo. Aquí es donde me divierto.

Answer 8

En mi experiencia, "lo suficientemente bueno" siempre incluye hacks, descuido, malos comentarios y spaghetti infierno, por lo tanto conduce a la falta de escalabilidad, errores, lentitud y evita que otros puedan construir de manera efectiva en su trabajo.

Pax, aunque reconozco sus puntos sobre las necesidades del negocio y el pragmatismo, hacer las cosas "por el libro" es para del lado comercial. "Lo suficientemente bueno por ahora" y "simplemente haz que algo funcione bien rápido" siempre lleva a mucho más trabajo-horas más tarde para arreglar todo, o simplemente rehacerlo cuando se trata de eso, que lo que pasaría haciendo bien la primera vez. "El libro" fue escrito por una razón.

Answer 9

Pienso en la programación como un arte. Un arte que requiere eficiencia. ¿Es el código eficiente incompatible con el hermoso código? Dudo que. De hecho, creo que cuando resuelves un problema de forma creativa puede significar un rendimiento multiplicado. No creo que la programación solo se deba a aprender nuevas bibliotecas para cada nueva necesidad, ni a seguir y corregir errores. Creo que debería ser sobre belleza. Por supuesto, el código no puede ser siempre arte, y a veces uno debe ser pragmático sobre los problemas encontrados.