¿Qué tipo de método de programación prefieres? Éxito vs. libertad

Question

¿Preferiría tener total libertad total sobre todas sus técnicas de desarrollo, o preferiría seguir un enfoque más seguro y aburrido que tenga una probabilidad significativamente mejor de trabajar al final? Hacker vs Ingeniero? Pintor vs electricista?

Answer 1

Me gusta hacer las cosas. Esto significa usar herramientas de desarrollo establecidas y un proceso razonable, mientras soy creativo en lo que hago dentro de ese proceso. La mayor poesía en el idioma inglés se escribió con estrictas reglas de metro y rima, y ??no parece menos creativa para ella.

Answer 2

La "libertad o nada" la actitud es juvenil y molesta, el mundo real no funciona de esta manera.

Dame un proceso establecido.

Answer 3

Economista. Si me da dinero y no es poco ético, estoy a favor.

Answer 4

Depende de si eres inteligente.

Si eres inteligente, entonces libertad. Harás tu propio éxito.

Pero el problema es que nadie puede decir honestamente si ellos mismos son inteligentes.

Answer 5

No, no creo que la libertad frente a lo aburrido sea válida. Un proceso ligero definido que también es flexible es ciertamente factible. Hasta que alguien pueda demostrarme que es experto en el desarrollo, probablemente no permitiré tanta libertad.

Seguir un proceso inelástico pesado también puede ser perjudicial.

Se necesita mucho sentido común, pero es algo difícil y todo esto varía entre desarrolladores y organizaciones. No hay una talla única para todos.

Answer 6

Personalmente, prefiero la libertad de probar nuevas ideas, nuevas técnicas, nuevos procesos, pero creo que debería autorregularse. Es decir, creo que las técnicas, procesos, etc. necesitan probarse beneficiosos. Exigir libertad de expresión personal en un entorno de equipo probablemente no sea una buena manera de construir el equipo, pero creo que el equipo debería estar abierto a mejorar a través de nuevas ideas. Sin embargo, una vez que el equipo haya adoptado un proceso / técnica, sería contraproducente continuar insistiendo en su propio camino (incluso si es mejor) si el equipo no lo ve de la misma manera que usted.

Answer 7

Esta no es una pregunta válida. Puede ejercer su libertad para seguir un proceso, o puede ejercer su libertad para no seguir un proceso. Ya sea que sigas un proceso o no, aún tienes libertad.

Answer 8

Es una falsa dicotomía. El proceso impuesto no se correlaciona con el éxito. Por ejemplo, en las compañías telefónicas, se impone una enorme cantidad de procesos a los desarrolladores de software (lectura ingenua del desarrollo 'en cascada') con el efecto de que se pierde mucho tiempo escribiendo documentos de diseño detallados, y cuando el software se entrega a los clientes de repente descubre que lo que pidieron no es lo que querían. En ese punto, los recursos están casi agotados y todos pierden. El proceso impuesto mata proyectos.

Por otro lado, cuando Amitabh Srivastava impuso algunos requisitos básicos de análisis y pruebas al equipo de Windows, las tasas de errores disminuyeron, y al menos entre mis amigos de Microsoft, la productividad y la moral aumentaron. Supongo que sucedió algo similar en el proyecto de KDE cuando comenzaron a requerir que todos usaran valgrind . De repente, no más errores de memoria y volcados de núcleo desconcertantes.

En general, creo que es más exitoso imponer herramientas útiles que imponer procesos . La evidencia a favor o en contra de la utilidad de una herramienta puede acumularse con bastante rapidez. El único 'proceso' que he visto es consistentemente exitoso es que más de un par de ojos deberían ver el código. El mecanismo por el cual se logra esta visualización no importa.

Freedom para desarrolladores es una pregunta completamente diferente. Soy afortunado porque tengo un trabajo donde tengo casi total libertad para elegir todo sobre mi entorno de desarrollo. (Ejemplo: trabajo en una tienda de Red Hat, pero tenía un presupuesto para comprar una computadora e instalar Debian). Dado que tengo más de 20 años de experiencia en el desarrollo continuo de software, generalmente puedo tomar muy buenas decisiones sobre qué idiomas y herramientas utilizar. utilizar. Pero la otra cara de eso es que puedo ser razonablemente productivo en cualquier idioma o entorno. Usar perl o C ++ podría retrasarme en un factor de 2 o 3, y usar Lua o Haskell me acelerará para ciertos problemas, pero al final llegaré allí.

Pero he trabajado con otros desarrolladores que tienen una zona de confort muy limitada en cuanto a idiomas y herramientas, y que elegirán alegremente una herramienta muy incorrecta para el trabajo si se les da la libertad de hacerlo. Una vez, como consultor, me pidieron que intentara ayudar a un grupo a acelerar un compilador que tardaba 24 horas en compilar pequeños programas. Resulta que las personas que lo habían escrito eran personas expertas en sistemas y habían escrito un compilador utilizando un motor de inferencia basado en reglas. Lo pusieron a funcionar, pero era la tecnología incorrecta para el trabajo.

También he visto que restringir a un desarrollador a un entorno o lenguaje particular no es garantía de éxito. Me considero un muy mal programador perl; Básicamente trato a Perl como awk con esteroides. Soy un completo idiota. Y, sin embargo, tuve que lidiar con el código Perl escrito por otros que era mucho peor que cualquier cosa que pudiera escribir solo porque nunca habían aprendido a pensar en problemas o en cómo organizar el código.

Creo que será mejor que deje de despotricar ahora.

Answer 9

Trabajar en grupos más grandes enseña ser los valores de procesos establecidos y documentados.

Mientras trabaje en un equipo pequeño (2-4 personas) donde conozca bien a todos y todos tengan un objetivo común, probablemente puedan trabajar muy bien sin tener un proceso definido.

Tan pronto como 10 personas tengan que cooperar en algo, querrás al menos algunas reglas básicas, para que todos estén del mismo lado.

Cuando estás haciendo un proyecto con 100 personas, no llegarás a ninguna parte, a menos que tengas reglas muy específicas y un proceso bien definido.

Personalmente preferiría si pudiera hacer lo que quiera y todos los demás trabajen de acuerdo con un proceso estricto ;-)

Answer 10

Hay diferentes aspectos de la libertad. Cuando no puede cambiar la mitad de la base de código porque ya está "probada" (incluso si está mal codificado), diría que es un caso en el que necesitas libertad, pero no creo que estés hablando de eso.

Libertad de estilo hacker, usar las herramientas necesarias para resolver el problema, y ??resolver el problema como un objetivo principal me aterroriza en estos días.

Nunca he visto código que no necesitara depuración / reparación en algún momento, y la depuración / reparación siempre parece tomar más tiempo que la codificación inicial, por lo que la primera ronda de depuración / mantenimiento / mejora lo más fácil posible debe ser tu objetivo principal.

Esto entra en conflicto con " Freedom " porque " Libertad " a menudo implica que puede elegir mecanismos que demorarán más en tratar con otras personas, y lo más probable es que otras personas hagan la primera ronda de mantenimiento.

Answer 11

¿Qué pasa si pones tu angustia por la libertad para ser creativo en nuevas áreas de proyecto en lugar de inventar otro proceso de desarrollo?

Answer 12

" Éxito vs. Libertad " implica que si eres libre de tomar decisiones, el programa no será un éxito.

Creo que realmente tienes que repensar esto. En mi experiencia, los desarrolladores deben ser GRATUITOS para elegir el mejor método de implementación, si es mejor después de la revisión que el "probado y probado". métodos, entonces será guardado y utilizado por el resto del equipo. Pero aún deben asegurarse de que el código que escriben tenga ÉXITO en el cumplimiento de las tareas que deben llevar a cabo.

Answer 13

" Libertad " en este caso solo parece una palabra emocionalmente positiva vinculada a un concepto desagradable. Podría ser fácilmente reemplazado por "terquedad" o "descuido". Incluso la pregunta en sí se enmarca como "lo que quiero hacer". frente a "lo que es probable que funcione".

Por supuesto, cualquiera es libre de seguir cualquier camino que elija. Pero personalmente no dedicaría un momento de mi vida a algo que no me importara, y si me importara, haría todo lo posible para maximizar sus posibilidades de éxito. No veo eso como "restrictivo" en absoluto.

Answer 14

La cuestión de si seguir con la sabiduría convencional o "pensar fuera de la caja" ha existido desde siempre en la mayoría de las disciplinas, no solo en la programación. Creo que debe decidirse caso por caso.

He estado en conferencias donde los trabajos más populares parecen ser análisis en profundidad de las cosas tal como son. No muy diferente de SO, donde las ideas populares se votan positivamente.

Esto estaría bien si no hubiera problemas serios en el campo. Gran parte (si no la mayoría) de software todavía está demasiado hinchado (en mi humilde opinión) y sufre problemas crónicos de rendimiento. Las cosas tal como son son estables, pero ¿son lo suficientemente buenas?

Creo que necesitamos nuevas ideas, y esas serán necesariamente impopulares, poco convencionales y riesgosas, por un tiempo.

Me alegra que SO permita que se discutan ideas no convencionales, no como llamas, sino como formas de cuestionar el statu quo.

Answer 15

¿No depende también de lo que vas a construir al final?

Estos tipos siguen procesos establecidos: http://www.fastcompany.com/magazine /06/writestuff.html