Bueno, o empieza a hacerlo bien.
Si me pidieran señalar un problema específico que mató a la mayoría de los productos de software, entonces definitivamente llamaría al anhelo de que los desarrolladores prevean el futuro distante. Esto se puede expresar de muchas maneras, pero el esquema general es aproximadamente el siguiente:
"Necesitamos implementar la solución {X}, a pesar de que hay una solución mucho más simple y más adecuada para nosotros {Y}, porque cuando {Z} suceda en el futuro, entonces {X} funcionará mucho mejor que {Y}" .Además, no hay ni puede haber información exacta sobre la probabilidad de ocurrencia del evento {Z}.
Aquí hay un par de ejemplos:
- ¡Necesitamos usar kubernetes y docker! Sí, un solo servidor hace frente a la carga actual y es fácil de configurar y mantener, pero cuando necesitamos una docena de servidores, será más fácil implementarlos con kubernetes y docker.
- ¡Necesitamos una arquitectura de procesamiento de datos distribuidos! Sí, hasta ahora una PC promedio se ocupa de todo, pero cuando tenemos una solución de grado industrial y los clientes demandan un tiempo de actividad de cinco nueves en SLA, estaremos listos para esto.
- Necesitamos contratar un equipo de desarrollo y crear un sitio web desde cero, a pesar del hecho de que sería mucho más rápido implementar algo basado en WordPress, porque cuando tenemos 100 veces más clientes que ahora, WordPress no será tan conveniente.
- Necesitamos usar la herencia en lugar de la composición, porque después de 5 años, la base del código crecerá para que sin ella no haya forma.
- Necesitamos escribir este código en C ++, a pesar del hecho de que en Python será varias veces más rápido, porque después de años procesará terabytes de datos y es posible que Python no pueda hacer frente aquí.
Recientemente escribí
un artículo sobre problemas imaginarios, aquellos cuya solución la gente se entretiene, porque resolverlos es más interesante que los reales. Esto también incluye estos intentos de prever el futuro. Incluso puede decir más: este es el problema imaginario favorito de la mayoría de las pequeñas empresas de nueva creación.
Pero no juntemos todo: tratar de estar preparado para el futuro puede ser útil si aborda esto sabiamente. Pero pocas personas aparecen sabiamente: las personas tienen fantasías, miedos, emociones y otros sentimientos humanos.
Lograr el éxito es más difícil que vivir con el éxito ya alcanzado
Cada persona a veces fantaseaba sobre cómo sería todo si fuera otra persona. Alguien rico, famoso, fuerte, dotado de poder. Pensar en ello es bastante interesante, y ocurre de alguna manera por sí solo, involuntariamente. Entonces viste una foto en la portada de la revista y pensaste, ¿qué haría en lugar de esta celebridad? Oh, entonces gastaría el dinero en esto, y si lo hiciera. Y también eso. ¡Y si aún pudieras volar y poseer superpoderes! Sí, eso sería genial!
Los desarrolladores de software también son personas, y también son susceptibles a las fantasías. Entonces, significa que Facebook construyó su plataforma sobre tales y tales tecnologías y se escala a mil millones de usuarios ... Bueno, no somos peores, y las tecnologías están disponibles, hagamos todo bien también, con una acumulación de mil millones de usuarios (aunque hasta ahora hay un centenar de ellos). Pero la magia de Facebook no estaba en la tecnología de escalar a mil millones de usuarios. Pudo dar a las personas el producto adecuado en el momento y lugar adecuados. El software, capaz de escalar hasta mil millones de usuarios, era una parte secundaria y menos importante de la empresa. Fue creado solo cuando se hizo necesario y solo como se necesitaba.
La medalla tiene dos lados:
a) Lograr el crecimiento es más difícil que mantener la escala.
b) La mayoría de los programadores excepcionalmente calificados y talentosos trabajan en productos que necesitan una buena escalabilidad.
El punto
"a" es fácil de reconocer. Piense por sí mismo: de todas las compañías de software que se hayan creado, solo, probablemente, aproximadamente el 0.05% alcanzó el nivel de millones de usuarios y miles de millones de ganancias. El resto se estrelló antes o recibió menos.
Por lo tanto, la mayoría de las fantasías sobre las características necesarias en el futuro para el software generalmente se reducen a tratar de resolver los problemas de este 0.05% de las empresas. "Aquí tenemos un equipo de 1000 desarrolladores, 10 millones de usuarios y una docena de grandes clientes corporativos con sus requisitos complejos, y luego necesitaremos ..." No, no lo necesitas. Con una probabilidad de 99.95%.
Pero decir NO a ideas tan tentadoras es difícil, porque destruye la fe en esas mismas fracciones de un porcentaje de probabilidad de éxito. Tenemos que dejar de presentarnos como propietarios del nuevo Amazon y volver a los problemas de hoy. Y hoy tiene 50 usuarios, de los cuales 30 son familiares y amigos. Sí, la conciencia del estado actual de las cosas puede desmotivar.
El punto
"b" tampoco ayuda a lidiar con la obsesión. Está claro que los mejores programadores trabajan en las principales empresas. Ya sea porque fueron creados gracias a su talento o porque las principales empresas pueden contratar a los mejores programadores. El principio de Pareto funciona aquí contra nosotros: es mejor para los programadores escribir libros, hacer presentaciones y diseñar mejores sistemas. Cada uno de nosotros escuchó de ellos estas fascinantes historias sobre clústeres tolerantes a fallas distribuidos en miles de nodos, procesando petabytes de datos utilizando software optimizado para algunas cifras de rendimiento increíbles. Pero la mayoría de nosotros no necesitamos pensar cómo construir un clúster en nuestra empresa aquí y ahora. Él simplemente no es necesario.
Entonces, cerrar los ojos y representar a su empresa en 5 años es grande, ¿no ayudará? ¿Es realmente necesario dejar de pensar en el futuro?
Por supuesto que no. Pensar en el futuro es bueno. Y diseñar software con una base para el futuro también es útil, pero debe hacerlo correctamente.
Diseño flexible, implementación imperfecta
Mejor hacer menos, pero bien. Muy pocos productos satisfacen realmente las necesidades de sus clientes. Para que hicieras
A y el 90% de tus usuarios necesitaran exactamente
A , nunca lo serán. El 90% de sus usuarios potenciales necesitan algún tipo de
B , y su
A es solo la alternativa más cercana a
B , y nadie vende ni vende
B él mismo, por lo que algunos de los compradores estarán satisfechos con un tit en sus manos.
¿Qué es bueno en este escenario? Una vez que obtenga los compradores, aún puede intentar comprender lo que realmente necesitaban y, finalmente, darse cuenta de esto. Bueno, o una alternativa un poco mejor a esto. La base de usuarios lo ayuda a estudiar el mercado, encontrar nichos en él y llenarlos. Tan pronto como busques este nicho, comienza a trabajar en él, aquí comienza tu crecimiento.
Y este enfoque es realmente productivo. Implementa algo pequeño, pero funciona bien, se lo entrega a los usuarios y luego escucha sus opiniones sobre su producto. Ya no adivina, no resuelve problemas imaginarios, no agrega complejidad innecesaria. Se adapta, agrega algo, elimina algo. Y esto crea su producto único.
Y de esta manera: cuanto más pequeña era originalmente su base de código, más fácil es adaptarla a algo nuevo.
"Odio el código y me gustaría verlo en nuestro producto" - Jack Diederich
Si hiciste que algo funcionara perfectamente, lo hiciste mal. Tenías que hacer grandes sacrificios en el camino. Tal vez fue una pérdida de tiempo o dinero, tal vez renunció a la flexibilidad, tal vez algo más. El ideal no se logra de forma gratuita.
El software no ideal es más viable. Es posible crearlo en un tiempo razonable y a un precio razonable. Con bastante frecuencia hace todo o casi todo lo necesario. Por imperfecto, por definición, deja espacio para su desarrollo y libertad de maniobra.
Diseño de arquitectura de software optimista: el futuro puede despertar agradablemente
Es importante recordar que el mundo que te rodea no es estático. Los problemas que surgen ante usted después de unos años pueden resolverse fácilmente con la ayuda de las tecnologías disponibles después de unos años. Muchas personas diseñan algo, no solo no teniendo en cuenta las oportunidades futuras, sino que generalmente dependen de herramientas que ya tienen décadas de antigüedad. Se limitan ni siquiera hoy, sino ayer.
Permítanme hablar sobre un ejemplo específico: diseñar sistemas distribuidos con la expectativa de estar preparados para cualquier crecimiento. Uno de los temores comunes que conducen a la creación de tales sistemas es el temor de que en algún momento su servidor no pueda servir a todos sus usuarios. Y realmente sucede. A veces Pero no en pequeñas empresas, no en nuevas empresas. Además, la mayoría de las personas que escriben software en 2018, por alguna razón, están seguros de que funcionará en servidores creados en 2005. Las computadoras mejoran cada año y se pueden alquilar buenos servidores no tan caros.
Permítanme describir un servidor "real" inicial de este tipo:
- Dos Xeons E5-2680v4 (28 núcleos y 56 hilos, camuflaje de 2.4GHz a 3.3GHz)
- 512 gigabytes de RAM DDR4-2400
- 2 SSD NVMe de 1.2TB cada uno (~ 3GB / s de lectura y ~ 1.5GB / s de escritura cada uno).
Sí, apuesto a que la mitad de los sistemas distribuidos del mundo se ejecutarán en este servidor por completo, con todos sus componentes y dependencias, sirviendo normalmente a toda su base de usuarios existente. Y esto está lejos de ser el mejor servidor hasta la fecha. Esto se puede tomar por un precio de 800 a 1300 dólares por mes (dependiendo de dónde obtenerlo). Puede alquilar una docena de estos por el salario de un ingeniero calificado en Londres.
Lo que sigue siendo bueno en este servidor es que el precio de su alquiler en 2 años caerá 2 veces.
Las computadoras evolucionan, evolucionan de manera muy lineal y previsible y continuarán evolucionando como se predijo, en algún lugar hasta el final de la década de 2020. Es difícil adivinar más, pero es poco probable que a la humanidad se le ocurra algo nuevo. Y la gente todavía recuerda el hierro de principios de siglo y teme que no sea suficiente para atender un par de miles de solicitudes por día.
Pero estamos hablando de hierro. Y piense en todo el software que aparece y se desarrolla alrededor. Pocas personas pensaron seriamente en el control por voz hace 20 años. Y mira el mundo de hoy: "OK Google", "Hola, Alexa", "¿cómo está el clima ahora, Siri?" Cualquiera que comenzó a escribir una interfaz de voz en el año 2016, solo logró el 2018.
¿Qué comenzar a escribir en 2018? Ah, si lo supiera :) Esto es algo que ya apareció en el horizonte, pero aún no se ha vuelto tan grande como para eclipsar al sol. Mira a tu alrededor, ¿tal vez notas algo así?
El progreso en el software es increíble. Completamente inadvertido, con la llegada de WASM, los navegadores se han convertido en máquinas virtuales universales. Después de 2 años, puede crear una aplicación versátil, compleja y de alto rendimiento compilándola exactamente para una plataforma: el ensamblaje web. Y comenzará en todas partes.
Pero la gente todavía vive en algún lugar en 2012. Usan Babel, aunque el 99% de los usuarios tienen al menos un navegador con soporte para ES6.
Nuevos lenguajes de programación aparecen constantemente. Y algunos de ellos son bastante buenos. Solo en los últimos 8 años, obtuvimos Go, Rust, Scale y D, todos encontraron su nicho. En los próximos 2 años, espero ver cómo Julia contribuirá a la programación científica. Y esto es justo lo que me preocupa personalmente y lo que sigo. La cantidad total de tecnología y conocimiento es increíble.
Pero me estoy desviando ...
Inspirar el futuro es relativamente fácil. Pero, francamente, además del progreso lineal del crecimiento de la productividad, es difícil imaginar lo que sucederá en 2 o 5 años. Algunas ideas están flotando en el aire, los equipos están trabajando en varios proyectos de software y hardware, pero ¿qué "disparará" a partir de esto?
Sin embargo, si desea preparar su software para el futuro, primero debe comprender el presente. Lo bueno en el presente es que ya existe, es observable, medible. Y todavía aguanta por un tiempo. Hacer que su software sea al menos relevante hoy es una buena idea. No estará preparado para las realidades de 2020 utilizando los enfoques de 2000. Pero el software escrito con enfoques relevantes para 2018 puede funcionar bastante bien en 2020.
Por lo tanto, no se niegue el placer de desarrollar software con una base para el futuro. Solo hazlo más correctamente. Considere no solo el desarrollo de su producto futuro, sino también el desarrollo de su ecosistema circundante. Todo lo que se pueda diseñar con flexibilidad debe diseñarse con flexibilidad. Esto le dará la oportunidad de maniobrar en el momento en que descubra de qué manera debe completarse esta maniobra. Y esto le ahorrará pasar tiempo preparándose para algo que nunca sucederá.