Si buscas «todo el mundo debería de saber programar» vas a encontrar muchas entradas. Hay muchas opiniones a favor de porqué programar es bueno para ti. Adquieres una nueva habilidad, cambia tu forma de pensar, te hace ver las cosas desde otra perspectiva.
En definitiva mucho crecimiento personal, desarrollo mental, etc. pero yo no quiero tratar ese tema. Que saber programar es algo bueno para la mente humana es algo de lo que estoy convencido. Es bueno como es bueno dibujar, leer, escribir, bailar, hacer deporte y aprender otros idiomas. Todas esas cosas son buenas. Y con buenas no quiero decir útiles, quiero decir buenas para el ser humano a nivel mental (algunas a nivel físico también pero eso es otra historia).
Pero no, eso no es lo que quiero tratar aquí. Lo que quiero tratar es muy concreto, y es que en cualquier industria/empresa que haga software (aunque esa no sea su fuente de ingresos) porqué todo el mundo debería programar.
Sí, así es. Si eres desarrollador de software y en tu empresa hay alguien que no programa, debería. Si trabajas en una empresa en la que se desarrolla software (sea o no para uso propio) y tu no programas, deberías.
Si no programas, deberías.
Es algo categórico. Todo el mundo tiene que programar. Programar en una empresa que hace software significa aportar al producto. A estas alturas, el que ha leído hasta este punto estará radicalmente a favor o en contra de este principio fundamental que de forma tan improbable se da en el tejido empresarial de cualquier industria, y ahora voy a matizar los comos y porqués.
Programar es una palabra muy grande.
No hace falta que te descargues todas las herramientas de desarrollo que tengan los ingenieros de tu empresa para empezar a colaborar (de verdad) en el producto que hacéis. No lo ibas a hacer, y no tienes por que hacerlo para colaborar.
La industria software ha crecido tanto (y tanto más va a crecer) que la programación es una parte más del desarrollo software. Por eso no considero correcto llamar hoy en día a los que hacen software «programadores» y si «desarrolladores».
Este neologismo adoptado del inglés tiene sentido en muchas áreas en las que no intervienen solo lenguajes de programación o programación clásica. El hecho de usar la palabra «programador» hace una distinción muy radical entre dos clases de trabajadores: los que programan y los que no. Esto no es bueno para la industria. El software es ahora muy amplio y su desarrollo se debe ampliar a toda la capacidad posible de una organización (que es todos los que colaboran en la empresa).
Un desarrollador es un experto en el area de conocimiento relacionada con la programación en lenguajes y usando herramientas de ese ámbito. Y es bueno que haya expertos que se dediquen a su especialidad, pero eso no implica que no puedan hacer nada más. Por su profesión conocen muchas herramientas software y saben lo que les gusta y lo que no les gusta de las herramientas que hacen. Por eso no se les debe considerar como meras máquinas de hacer software si no también usuarios avanzados de este. Su opinión no es la de cualquiera, es la de alguien que usa mucho software y también lo puede producir. Sabe lo que es fácil de hacer y lo que es muy complejo, y ese conocimiento es muy valioso para la organización.
En el otro lado de la mesa estarían entonces todas aquellas personas que colaboran en una organización pero que no programan con lenguajes de programación y las herramientas del ámbito.
Interfaz
En el desarrollo web una gran parte de la aplicación es la interfaz. La interfaz web es un documento (muy) enriquecido que también permite interactuar al usuario con el. A veces las funcionalidades de interactuación son tantas que se pierde el concepto de documento. Pues bien, estos documentos (paginas web) se componen por lenguajes de marcado y lenguajes de estilo, esto es HTML y CSS. Estos no son lenguajes de programación, pero forman parte del desarrollo de la aplicación.
El arte no son herramientas, pero los artistas no hace solo arte conceptual. Puedes encontrar un equipo de diseñadores (o al menos un diseñador) en la mayoría de empresas que hacen software. Después de diseñarlo hay que implementarlo y ¿es esto menos importante que la funcionalidad que se ofrece detrás de la interfaz? para nada. Puede que haya quien lo valore menos; eso no lo hace menos necesario.
En una conferencia hace ya algún tiempo escuché a un desarrollador comentar que en su empresa el CEO hacía cambios en el la hoja de estilos de la página. Muy probablemente serian nimiedades o pequeños bugs sueltos aquí y allá en partes para nada cruciales del negocio … pero los hacía. Ese era el nivel de implicación en su producto. Exigir sin saber es fácil, aquel hombre colaboraba.
Despliegue
La parte más valiosa del software no es en realidad programarlo. Estuve muchos años convencido de que era así. Mejores funcionalidades y más accesibilidad hacen que la gente abandone un programa por otro. O quizás solo un pequeño matiz entre dos aplicaciones ya hace que dejes una para abrazar la otra. De manera competitiva es muy importante lo que tu software hace y como lo hace, así como que este libre de defectos. Y estos aspectos sí tienen gran importancia, de hecho son lo segundo más importante. Lo que es lo más importante del software es entregarlo. En ingeniería de software esto se llama despliegue.
Si tienes un software genial que tiene todas las funcionalidades necesarias para lo que necesita todo el mundo y no esta accesible para nadie ¿de que sirve?.
Si tienes un software parcialmente terminado, lleno de defectos y hasta feo, pero disponible a todo el mundo, ya tienes producto.
Cuidado aquí, no estoy haciendo apología de hacer malas aplicaciones si no de tener buenos sistemas de despliegue. Hay empresas especializadas en hacer software de despliegue, así que en realidad no te hace falta hacértelo tu mismo solo tienes que configurarlo a tu gusto y esto puede ser a veces complejo dependiendo de tus necesidades. Esto consiste en automatizar tareas, en pasos concretos, y aunque muchas veces sea con herramientas con interfaz gráfico, el fin no deja de ser el mismo.
Calidad
Y una vez entregado se acabó … pues no, hay que testear. Hay tests unitarios, de componente, de sistema, integración. Pueden ser caja negra, caja blanca. Visuales, de rendimiento … en fin, me abruma pensar en catalogar todas las clases de testing de software que existen.
La calidad es algo que diferencia de manera competitiva a un producto, y toda empresa que tenga un plan de negocio a medio plazo sabe que el testing en la industria del software es algo fundamental. Un software sin defectos no te hace ganar dinero per se, un software con defectos te puede hacer perder mucho dinero (o dejar de ganar), y las empresas lo saben y le dedican muchos recursos a ello.
Si el gasto en desarrollo es inversión para ganar dinero, el gasto en calidad es dinero invertido en no perderlo.
Escribir pruebas automáticas es desarrollar software, solo que ese software comprueba que el producto hace lo que debe de hacer. En si eso es programar al más puro estilo, pero eso no es lo único que se hace cuando se desarrollan tests. Los tests hay que definirlos, programarlos, insertarlos en tu flujo de despliegue y actualizarlos si se cambia la funcionalidad del programa. Algunas cosas las hacen los desarrolladores, otras las puede hacer cualquiera. Cualquiera que se precie.
Documentación
La documentación no es solamente tener una web que dice qué hace el producto, el cómo es tanto o más importante. Muchos proyectos han triunfado porque tenían una documentación mucho mejor que los demás. Ahora mismo me viene a la mente jQuery, que aunque ahora es hasta odiado por algunos, fue el numero uno de los frameworks javascript durante mucho tiempo. El motivo, el API estaba escrita para humanos. No tenias que irte al código fuente para ver que hacia y casi cómo lo hacia para entender una función especifica, e incluso tenia varios ejemplos de uso que se adaptaban a la mayoría de las necesidades de los que usaban el producto.
¿Cómo se consigue una documentación así? Estando cerca del código. Si sabes que hace y cómo lo hace tu producto, te será mucho más fácil explicárselo a otro.
Eso está bien para la documentación externa. Para la parte de tu producto software que expones al mundo esta genial pero ¿Y la documentación interna? Aquí se abren dos temas. El primero es que el código debe ser autoexplicativo. En muchos años desarrollado no he visto ningún código completamente autoexplicativo. Es más, no he conocido a nadie que haya visto o conocido a alguien que conozca a alguien que ha visto un código así. Pero hay códigos mejores que otros, y mejorar tu código es cuestión de refactorizarlo, para lo que hay que saber programar.
El segundo tema en cuanto a documentación interna es el análisis de requerimientos. Que es lo que nos pide nuestro stakeholder que haga el producto. Primero hay que recoger información, entender lo que se pide, refinarlo… en general etapas de negociación que hacen humanos con humanos. De esto sale una documentación entendible por humanos también. Y ese es el final. Si la persona que hace este proceso puede también crear test (de la capa de complejidad que considere oportuna) este código de test se podrá usar como documentación viva en el código. Esto también da a la gente que desarrollará el producto una idea de que se pide en el test de aceptación. Más agilidad en las comunicaciones del equipo, más claridad en lo que se pide, producto entregado antes y mejor.
Automatización de tareas
Un script es un conjunto de instrucciones que le dicen al ordenador lo que debe hacer. Esto es lo que haría un usuario paso por paso, pero todo junto en un fichero de texto. Aunque este fichero de texto nunca produzca un programa (compilado) esto no se va muy lejos de lo que es en si un programa en la manera clásica.
Con esta explicación puedes pensar: «Bueno, esto se parece tanto a programar, que es programar». Pues sí, hacer scripts es programar, y es una de las tareas básicas de una lo que los DevOps hacen, pero no la única. DevOps son una especialidad en si misma muy necesaria en la industria software y no me voy a parar a describirla porque daría para varios libros.
La clave aquí es que después de tantos años de industria del software, los mismos problemas le han sucedido a mucha gente que las ha resuelto de forma parecida. Incluso muchas veces las soluciones se han compartido en forma de herramientas de software libre. Los flujos empresariales (salvo excepciones) no son muy distintos unos de otros y se pueden automatizar con herramientas que son por lo general muy configurables.
Aquí estoy abriendo la puerta al simple uso de herramientas de distinta complejidad especializadas según el sector. Se puede argumentar en contra que el uso de software no es programar, y en eso estoy de acuerdo, pero hay mucho software que te permite cofigurarlo con herramientas gráficas.
Existen lenguajes de programación visuales, en las que el programador solo tiene que saber lo que quiere hacer, y arrastra y suelta bloques de instrucciones para realizar su programa.
La mayoría de estos lenguajes tiene una finalidad educativa, sin embargo hay software empresarial que también integra este tipo de interfaces para automatizar tareas repetitivas en flujos empresariales.
La automatización de tareas en si es un concepto muy global y su puesta en practica es especifica de cada herramienta, pero en definitiva buen el conocimiento de las herramientas empresariales por parte de los trabajadores (que no son programadores) es fundamentar, y una de las claves del aumento de productividad de la organización.
Que después de esta perorata no se te ocurre nada aplicable a tu puesto de trabajo, ¿has hecho alguna tarea manual 3 veces o más? pues entonces se puede automatizar, solo necesitas que un experto monte la infraestructura para que tu lo aprendas a hacerlo.
Producto producto producto
Un gran comercial puede vender de todo, chicles, pipas, caramelos y software. Da igual el mercado, su fuerte son las relaciones sociales. No es lo que vende si no el como lo vende y a quien.
No todos los mercados son iguales, y los productos de consumo y la herramientas no tienen la misma finalidad. Tampoco las leyes son las mismas para vender chicles que requieren cumplir legislación alimentaria, que sierras de calar que están sujetas a otras leyes y su mercado funciona de otra manera. Pero ¿porque hace falta que el comercial sepa como esta hecho el producto? es un producto, que lo venda y ya está.
Pero los alimento, bienes de consumo y herramientas en general tienen algo muy importante en común: están hechos por máquinas.
Toda industria necesita trabajadores humanos, incluso cuando se automatizan procesos y se produce más con menos trabajo humano, aun queda una capa en la que no nos fiamos de la maquinas y queremos a una persona que nos diga que todo va viento en popa «de verdad». Pero por mucho que avanza la ciencia informática en el software todavía no es así.
Hasta que skynet tome conciencia de si misma y decida que los humanos somos un peligro, el software va a tener que seguir haciéndose con mano de obra humana, y esto le atribuye unas características muy particulares.
Ante la duda de si los comerciales no tienen motivos para conocer como esta hecho el software yo me hago la pregunta al revés: ¿Porqué un comercial no tiene que saber como hacer software?
Me estremezco solo de pensar en que un comercial va a venderle a un cliente unas características inventadas, que la empresa va a tener que desarrollar a prisas y carreras generando defectos por todas partes.
Conocer tu producto, en la industria de software tiene que pasar por conocer sus interioridades. Saber que hace y que no, que defectos tiene, y cuales se van a resolver pronto y cuales van a tardar mucho en arreglarse. ¿Se puede vender software sin saberlo? Claro que si, se pueden hacer muchas cosas aun siendo ignorante, pero mejor para todos si se conocen.
Como buen comercial tienes que ir un paso más allá de encontrar un defecto en tu producto. Tienes que decirle a los expertos capaces de arreglarlo que falla, cuando falla y si eres capaz de decirles el porqué tendrás su agradecimiento eterno, y eso pasa por estar cerca del código. Tu ayudas a los desarrolladores a hacer su trabajo y ellos te ayudaran a hacer el tuyo. Un producto sin defectos y que asombra en las demos se vende mucho mejor que uno que falla como una escopeta de feria. El valor añadido es clave en esta industria.
Por otro lado las mejoras no solo vienen de la parte de reducir defectos, también de aumentar el valor añadido a bajo coste. Estando cerca del cliente, el comercial conoce los matices del uso de la aplicación. Si un comercial conoce su producto, sabe si algo que aporta mucho valor se puede desarrollar con mucho o poco coste, con lo que puede hacer peticiones de mejora mucho más al detalle acelerando así el proceso de entrega.
El producto software
Programar es bueno para ti y es bueno para tu organización. La especialización en tus tareas no implica no hacer nada más que eso. Hoy en día prácticamente todo requiere una forma de programación.
No hay una única forma colaborar haciendo software y todas deben estar cerca del código fuente, porque eso es lo que es un producto software, pero no solo eso.
Un buen producto software es un código fuente desarrollado, testeado, documentado y entregado de manera ágil, eficiente y frecuente, que permite al publico usarlo de manera rápida y sencilla.
Son unos requerimientos muy altos, pero estoy hablando de un BUEN producto software, por eso hace falta mucha gente trabajando en el, en muchos ámbitos distintos, todos cerca del código. Por eso todo el mundo en una organización debería colaborar para mejorar el producto, todo el mundo debiera aportar en cada fase des su desarrollo, todo el mundo debería programar.
