¿Cuáles serían buenos argumentos de hecho para convencer a la gerencia de alto nivel de considerar la programación funcional? [cerrado]

Hay toneladas de argumentos "teóricos" sobre por qué la programación funcional es una buena idea (demasiados para que haya quedado como una pregunta abierta, y correctamente).

Sin embargo, la mayoría de ellos son argumentos elaborados desde la teoría ("elegancia", etc.) o dirigidos a los desarrolladores.

El problema es que la mayoría de ellos son completamente inútiles cuando el objetivo es presentar la idea a la alta gerencia de una gran empresa , algunos de los cuales ni siquiera son desarrolladores, y todos se preocupan principalmente por los argumentos comerciales : costos, gestión del capital humano , entrega de productos, servicio al cliente e ingresos; así como hechos cuantitativos sobre puntos teóricos que no pueden respaldarse con hechos.

¿Hay algún argumento convincente para presentar para abordar esas preocupaciones comerciales en cuanto a considerar la adopción de la programación funcional como un concepto (no un lenguaje específico), frente a la combinación típica de procedimientos / OOP, por ejemplo, Java / C ++ / (Perl | Python) .

Preferiblemente, estoy buscando argumentos cuantitativos y / o basados ​​en investigaciones o estudios de casos. Por ejemplo, "de acuerdo con esta referencia, la tasa de errores de los sistemas multiproceso en Lisp / F # es 10% superior a la de Java" u "80% de los mejores graduados que expresan preferencias de la tecnología deseada denominada programación funcional como uno de los 3 principales intereses".

Sé que Graham presentó casos de uso de programación funcional para un estancamiento y estaría abierto a algunos de sus argumentos, suponiendo que puedan ser válidos para una empresa establecida más grande.

_{ps Estoy perfectamente consciente de que puedes hacer algo parecido a la programación funcional en Perl, probablemente Python y (posiblemente) incluso Java 8 o C ++ 14. Pero eso no significa que una organización que usa Perl, C ++ o Java apruebe funcional vs OOP / enfoques procesales incluso en esos idiomas}

_{Para los propósitos de este lenguaje, "grande" se define como lo suficientemente grande como para tener un grupo dedicado de ingeniería / herramientas de desarrollo, que dicta lo que todos los desarrolladores pueden usar / hacer; y al menos cientos de desarrolladores de gama baja} .

Hay un argumento muy simple, que al menos podría divertir a la gerencia.

Es bien sabido que las computadoras modernas no se están volviendo "más rápidas" como solían ser, porque la escala de frecuencia, por ahora, llega al límite. Aumentan su productividad potencial al agregar núcleos.

Esto implica que para beneficiarse más de esta arquitectura, los programas tienen que estar en paralelo. Pero la programación paralela es mucho más difícil que la secuencial, debido a la gran cantidad de nuevos desafíos que conlleva (consulte el artículo de Wiki para obtener una descripción completa).

La programación funcional ayuda a deshacerse de algunos de estos desafíos, por ejemplo, las condiciones de carrera no se aplican si solo usa variables y métodos inmutables sin efectos secundarios. La curva de aprendizaje para la programación funcional es a menudo empinada, pero la curva de aprendizaje para la programación paralela puede ser aún más pronunciada y nada intuitiva.

Entonces, si el desafío es escribir programas más eficientes de una manera más eficiente, uno puede comparar los costos de capacitar a las personas para escribir programas paralelos con los costos de capacitar a las personas para que aprendan programación funcional, y los riesgos que ambos enfoques pueden traer.

Con respecto a los lenguajes mixtos (que admiten el estilo de programación funcional e imperativo): desde un punto, pueden ser útiles para la transición (las personas pueden comenzar a usarlos de forma "familiar" y aprender gradualmente nuevos enfoques). Desde otro punto, esto podría ser una bendición disfrazada, porque las ventajas potenciales que brinda la programación funcional podrían cancelarse con el código torpe de alguien. Se puede mitigar esto estableciendo pautas de codificación claras (ver, por ejemplo, " Escala efectiva " de Twitter), aunque seguir las pautas requiere un cierto nivel de madurez del equipo. Desde este punto de vista, los lenguajes funcionales puros podrían ser "más fáciles" para el desarrollo de software debido a las reglas más estrictas que imponen por diseño.

Te estás acercando a esto desde el lado equivocado. En la mayoría de las empresas, la administración no es responsable de "elegir el paradigma de programación", son (o al menos deberían ser) responsables de hacer que el equipo funcione de manera eficiente. Si todo su equipo está convencido de que la programación funcional mejorará la velocidad o la calidad de su trabajo, tampoco debería ser demasiado difícil convencer a la gerencia. Además, si su equipo solo comienza a usar construcciones funcionales en sus lenguajes de programación establecidos, y todos están contentos con eso, ni siquiera debería tener que pedir un permiso (diablos, un no programador puede que ni siquiera entienda la diferencia entre construcciones funcionales y funcionales, entonces ¿por qué quieres discutir ese tema con él?).

Pero tenga cuidado, si el resto de su equipo tiene una opinión diferente sobre FP, y comienzan a quejarse del código funcional suyo que otros miembros del equipo no entienden, podría tener problemas con la administración, por una buena razón, ya que en tal caso, el equipo pierde eficiencia.

Entonces, la esencia es: convencer a otros miembros del equipo, o los líderes de su equipo, pero no a la gerencia de alto nivel.

EDITAR: debido a su comentario, en realidad, esta es una respuesta a su pregunta ;-). El único argumento fáctico del que estoy hablando es "todo el equipo piensa que FP es útil para hacer el trabajo . En mi humilde opinión, ese es el argumento con la mayor probabilidad de ser aceptado por la gerencia de alto nivel, y es muy práctico. Tratar de usar argumentos técnicos para las personas no técnicas, rara vez funciona directamente, no porque sean "demasiado tontos para entender el razonamiento técnico", sino porque son lo suficientemente inteligentes como para saber que las decisiones técnicas deben ser tomadas por expertos técnicos, y también son lo suficientemente inteligentes como para no confiar en opinión de un solo experto.

Para comprender por qué la programación funcional no se ha apoderado del mundo, debe comprender el pensamiento corporativo detrás de las decisiones del lenguaje de programación. Para elegir Java por un momento:

1. Hay ejércitos de programadores disponibles que pueden escribir resmas de código Java ordinario. Esto no es cierto para los programadores de Lisp o Haskell (o incluso Scala).
2. Todos los demás están usando Java, por lo que debe ser bueno. Corrolary: los gerentes no tienen que justificar su elección de Java versus algún lenguaje oscuro del que nadie en la estructura de comandos haya oído hablar.

Si su organización ya está atrincherada en el Reino de los sustantivos , simplemente no va a suceder un cambio general en la programación funcional. La elección del idioma (y todas las demás opciones que la rodean) ya está profundamente arraigada en la cultura corporativa.

Asumiendo que su objetivo es crecer como desarrollador de software, su mejor apuesta es

1. Incorpore conceptos funcionales en sus programas existentes donde sean útiles y apropiados,
2. Use nuevas funciones de lenguaje funcional a medida que se agregan al idioma, y
3. Aprenda patrones de diseño orientado a objetos, algunos de los cuales existen para superar las deficiencias del lenguaje en los lenguajes OO que no están presentes en los lenguajes funcionales.

Los argumentos de Paul Graham realmente solo se aplican a las nuevas empresas, y ha habido una serie de historias de advertencia de compañías que comenzaron a usar lenguajes puramente funcionales, pero luego fueron compradas por otra compañía cuyo primer negocio fue convertir inmediatamente la base de código funcional a un lenguaje OO para que sus desarrolladores de software existentes puedan entenderlo.

En mi experiencia (algo cínica), haber trabajado para una tienda donde usamos programación funcional y entrevistado en varios otros:

1. Siempre hubo un CTO y otras personas técnicas de alto nivel que tenían experiencia con la programación funcional y lograron convencer a los ejecutivos no técnicos de ella. (Y por cierto, estas personas están mejor calificadas para responder a su pregunta que yo).
2. Una vez que estas personas abandonen la empresa y sean reemplazadas por personas que no tienen esta inclinación, las cosas se irán al sur. Los nuevos muchachos echarán la culpa de todo lo que sale mal (incluidos, y particularmente sus propias fallas) al extraño lenguaje de programación y paradigma utilizado para construir lo que vino antes. Marginarán a las personas restantes con habilidades de programación funcional, expulsándolos de la empresa. El sistema construido en el lenguaje funcional se deteriorará sin mantenimiento. Este tipo de cosas, en mi opinión, es el mayor riesgo que una empresa asume si adopta un lenguaje funcional y no debe subestimarse.
3. La organización debe tener una cultura de "construir en lugar de comprar" para que esto funcione. Porque adoptar un lenguaje funcional significará menos opciones de "compra".
4. Casi siempre hubo algún compromiso con los detractores técnicos y no técnicos de la idea. El más común de estos compromisos es que cualquier lenguaje que no sea JVM fue simplemente fuera de consideración; Se propusieron Clojure y Scala, Haskell y O'Caml salieron de la nada.

Cosas a tener en cuenta para la alta gerencia cuando / si la alta gerencia está involucrada en la selección de lenguajes de programación (lo cual es extraño, deberían dejarlo en manos de personas confiables y conocedoras (tanto en tecnología como en negocios):

• Productividad
  • Empleados actuales y futuros
  • Todos los roles (arquitectos, desarrolladores, probadores, OP, ...)
• Plataformas soportadas
  • Sistemas operativos (hardware)
• Editor del lenguaje / plataforma
  • Licencias
• Madurez del lenguaje / plataforma
  • Apoyo de / por el editor y / o comunidad
  • Bibliotecas
• Migrar la base del código actual
  • O integración con

Tenga en cuenta que estos no son específicos de los lenguajes de programación funcionales. Estos tampoco son argumentos a menos que proporcione datos con estos. No podemos proporcionarle los datos, ya que dependen completamente del entorno de su empresa. Lo único que podríamos hacer es recopilar datos de la web para mostrar cuánto conocimiento e interés hay para un idioma específico. Tenga cuidado al traducir muchas preguntas en StackOverflow o muchas etiquetas en Linkedin a un idioma que sea popular.

No creo que los argumentos o los hechos ayuden. Y ciertamente no sin mencionar los problemas que desea resolver.

Contra la creencia común y la autoevaluación típica, muchas decisiones se toman en base a la intuición. Y a menudo estas decisiones son muy buenas, porque incorporan en un nivel subconsciente mucha experiencia del individuo que toma la decisión.

Si desea impugnar una decisión como "Nos apegaremos al lenguaje similar a C hasta el final de todas las computadoras", debe hacer algo más que proporcionar algunos argumentos.

Probablemente, el primer paso sea descubrir a las personas y las razones detrás de la decisión de que la alta gerencia debería tener algo que decir en esas decisiones técnicas. Por supuesto, solo puedo adivinar aquí, pero es muy probable que tengan un historial de decisiones tomadas por personal técnico que salió mal. Seamos realistas: la mayoría de los desarrolladores no son muy buenos para tomar decisiones (incluso técnicas) a nivel de empresa.

Una vez que haya encontrado a estas personas, hable con ellas para ganar confianza. Posiblemente el mejor enfoque es: escucharlos. De qué están preocupados, cuáles son los riesgos y las posibilidades que ven. ¿Cuáles son los problemas que enfrentan? A partir de aquí, puede avanzar para involucrar a la gente de tecnología en este tipo de decisión. La administración a menudo no quiere realmente tomar estas decisiones, pero no confía en otros con ella. Entonces, si su equipo comienza a involucrarse en la decisión arquitectónica y demuestra que las decisiones que propone son una buena gestión, podría estar dispuesto a confiar en usted / su equipo.

Importante para llegar a decisiones arquitectónicas sólidas es:

• Recopilar aportes de los interesados ​​(Gestión, Usuarios, Administradores, Ventas, Clientes ...)
• Basar las decisiones en esa entrada
• Comuníquese claramente: cuáles son las decisiones (propuestas); Qué riesgo pretenden mitigar; Qué intereses en conflicto son y con cierta demora: qué tan bien funcionaron.

Si trabaja para una gran empresa con más de 10 000 empleados, prepárese para aprender algunas de las siguientes lecciones.

• la velocidad de codificación no es realmente relevante para el resultado final.
• cosas como la mantenibilidad en la escala de décadas es.
• Los problemas que cree que puede resolver utilizando lenguajes funcionales no son realmente relevantes para el resultado final
• problemas como la capacitación de 1000 desarrolladores, la resistencia natural al cambio y el mantenimiento de una base de código escrita por desarrolladores con menos de 5 años de experiencia en la tecnología utilizada son.

Una vez que haya alcanzado un nivel de confianza para que sus argumentos sean escuchados y considerados, también habrá establecido una forma de reunir y considerar los requisitos en los que usted, su equipo y la gerencia confían.

Si este proceso produce la recomendación de utilizar un enfoque funcional en ciertas áreas que haya terminado.

Si este proceso produce la recomendación de ignorar los enfoques funcionales que van más allá de lo que el lenguaje de programación principal actual le ofrece, también habrá terminado.

La mala noticia es: dependiendo del tamaño y el estilo de la empresa, esto podría llevar fácilmente un par de años o décadas.

La buena noticia es: aprenderás mucho en el camino.

Dado que el primer paso es comenzar a hablar y especialmente a escuchar a la alta gerencia, recomendaría comenzar con la lectura de Just Listen .

Un buen enfoque sería demostrar que se muestran buenos resultados en la industria y se adoptan.

Puede obtener algunos datos de:

• http://www.quora.com/What-companies-use-a-functional-language-as-an-official-language

• http://pchristensen.com/blog/lisp-companies/

Idealmente, trate de hablar con los gerentes de algunas empresas que cotizan en bolsa, especialmente si están en su industria, y obtenga números y testimonios de ellos.

Google tiene muchos otros enlaces similares para Haskell, OCaml, etc.

Vienes a esto desde la dirección equivocada.

Estás tratando de convencer a la administración de un cambio a un paradigma funcional para tu propio entretenimiento y estás tratando de generar argumentos para apoyar esto que no tienen nada que ver con la verdadera razón por la que lo quieres. De lo contrario, no necesitaría hacer la pregunta, porque podría enumerar sus argumentos desde la parte superior de su cabeza.

Más bien, en lo que debería estar pensando es en qué necesita el negocio actual y cómo se sirve mejor. Si sucede que se sirve mejor usando un paradigma funcional, entonces, ¡sí! - Puedes jugar. Pero si realiza un análisis justo, teniendo en cuenta las necesidades comerciales operativas, la capacitación necesaria de los compañeros de trabajo, los antecedentes de futuros programadores, el mantenimiento, etc., a menudo no lo será.

La alta gerencia sin habilidades técnicas no debería preocuparse por aspectos técnicos como el uso de paradigmas funcionales. Este no es su dominio de experiencia, y huele a microgestión. ¿Por qué no están delegando esas decisiones a personas que realmente tienen las habilidades requeridas?

Dicho esto, aquí hay algunos consejos para convencer a las personas con antecedentes técnicos (primer caso) y aquellos sin uno (segundo caso).

Primer caso

Si está hablando con personas que conocen la programación , comparar código escrito sin paradigmas de programación funcional y el mismo código escrito en estilo funcional puede ser lo suficientemente convincente:

Ejemplo de código C # que usa un estilo imperativo:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

El mismo código reescrito con la programación funcional en mente:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

Luego pregúntales:

1. ¿Cuántos errores puede cometer un programador en la primera muestra? ¿Qué hay del segundo?

2. ¿Qué tan difícil es detectar errores?

3. ¿Qué tan difícil es modificar el código?

Los tres factores influyen en la productividad y, por lo tanto, en el costo del producto.

Segundo caso

Si se trata de personas que no conocen la programación, no hay muchas cosas técnicas que pueda decirles. Una de las formas de convencer es mostrar el impacto real de los paradigmas funcionales en su trabajo y el trabajo de sus compañeros de trabajo.

Por ejemplo, compare dos proyectos realizados por el mismo equipo, uno con FP y otro sin usarlo. Mostrar que la cantidad de errores es mucho menor o que este fue el primer proyecto que la compañía entregó a tiempo debería ser lo suficientemente convincente.