archivo

Archivo de la etiqueta: simplicidad

Es importante tener en cuenta segundas o terceras opiniones y reflexionar sobre la posible solución a un problema cuando la misma parece compleja a priori y por tanto requeriría un esfuerzo significativo para su realización.

Este ejercicio puede ahorrar días o incluso semanas de programación a lo que habría que añadir que probablemente la solución más simple tenga aparejada una menor deuda técnica.

Es posible que la solución simple implique alguna modificación sobre la dinámica de funcionamiento de la solución que especificó el usuario (es decir, que no sea un aspecto exclusivamente técnico), en estos casos es fundamental exponérsela y probablemente la acepte siempre y cuando la finalidad de la funcionalidad no varíe, hay que tener en cuenta que el usuario cuando realiza la especificación, por más que incluso la haga debatiéndola contigo, no tiene en consideración todas las opciones posibles sino la que en ese momento le viene a la cabeza o la que estuvo pensando la semana anterior.

Si te precipitas probablemente tardarás mucho más que si se analizan las posibles alternativas de solución. Al fin y al cabo será cuestión simplemente de esperar horas o días para madurar qué camino es el más óptimo.

Siempre agradecerás una solución simple, muchas desviaciones en los proyectos se producen precisamente por no dedicar suficiente atención a disminuir la complejidad técnica y funcional.

No importa que la idea no la hayas tenido tu, lo importante es el proyecto y éste es el resultado de la colaboración de todos los que participáis en el mismo. Tenemos el síndrome de la primera piedra, que consiste en que queremos ser nosotros los que coloquemos siempre el primer ladrillo pese a que el siguiente que se ponga sea el quinientos. Es importante dejar el ego a un lado para poder escuchar a tus compañeros.

Para Gordon Bell (traducción libre): “Todo gran desastre computacional es consecuencia de tomar demasiadas ideas y ponerlas en un solo lugar”.

O lo que es lo mismo, consecuencia de buscar soluciones demasiado complejas sin pasar por otras soluciones intermedias más simples y/o sin pasar por un proceso previo de filtrado que trate, tal vez, de ser menos ambicioso en alcance a cambio de un enfoque más realista y efectivo.

Tener un amplio abanico de ideas donde elegir es una situación preferible a la escasez de las mismas pero siempre y cuando se gestionen con moderación, a eso se refiere Gordon Bell con su cita.

Si se toman muchas de ellas de una sola vez, sin reflexionar suficientemente sobre las mismas (o incluso haciendo esa reflexión) corremos el riesgo de desperdiciar esfuerzo ya que es posible que la hipótesis o visión de partida sobre determinados aspectos del producto sea equivocada y nos haga tirar una gran cantidad de trabajo que se podía haber evitado realizar si se hubiera optado por un desarrollo centrado en lo realmente relevante.

Niklaus With dijo (traducción libre): “Uno de los principales motivos de la complejidad es que los proveedores de software adopten sin crítica casi cualquier característica que los usuarios desean”.

Se puede adaptar la postura cómoda, que no quiere decir que sea sencilla, de limitarnos a recoger las especificaciones de los usuarios sin expresar una visión crítica.

Esto implica que nos guardaremos la opinión sobre la complejidad o simplicidad de la solución planteada, sobre la conveniencia de priorizar determinadas tareas sobre otras, en definitiva, no ponemos a disposición del product owner o del responsable funcional nuestro conocimiento y experiencia.

El desarrollo de software debe ser colaborativo porque las perspectivas, habilidades, conocimientos y experiencias del conjunto suman siempre más que cada una de ellas por separado.

¿Por qué adoptar esa posición? A veces, en función de la naturaleza del product owner, la confrontación de las opiniones puede originar desgaste y en cualquier caso siempre vas a trabajar más ante la necesidad de argumentar tus opiniones y de consensuar soluciones.

Sin embargo, en muchas ocasiones, la elección de esa postura es el resultado de arrojar la toalla como consecuencia de que el usuario ni quiere ni se deja asesorar.

El product owner debe definir la línea de desarrollo del producto, es su responsabilidad, pero también debe tener la capacidad de escuchar las recomendaciones de todo el conjunto de personas que colaboran en el proyecto, si deja esto de lado, probablemente la obtención de valor será más lenta y el producto resultante en cada iteración tendrá un nivel de complejidad mayor al necesario.

Los desarrolladores deben aportar, no solo su capacidad para desarrollar el software, sino también poner en valor su perspectiva y experiencias.

Para Austin Freeman: “la simplicidad es el alma de la eficiencia”.

Cuando como desarrolladores asumimos que el producto se construye mediante aproximaciones sucesivas desde soluciones más simples y que no hay nada más productivo que evitar el desperdicio de esfuerzo en la implementación de funcionalidades no necesarias o que todavía no se han madurado lo suficiente, hemos dado un paso muy importante para tratar de maximizar la relación valor/inversión, lo cual supone una ayuda significativa en los diferentes proyectos en los que trabajemos.

Pero los desarrolladores nos debemos limitar a hacer nuestro trabajo y a asesorar a los responsables funcionales, por lo que independientemente de que tratemos de aplicar principios de simplicidad a nuestros trabajos no será suficiente si los encargados de definir la línea de desarrollo del producto no lo aplican también.

Una vez superado nuestro impulso de querer terminar demasiado pronto (y no es fácil conseguirlo), toca tratar que los usuarios piensen también en simple y eso es complicado porque suelen pensar en soluciones de máximos o en asegurar un buen número de funcionalidades desarrolladas, en lugar, tal vez, de ser menos ambicioso y tal vez llegar a menos pero mejor y con mayor valor.

La eficiencia es invertir adecuadamente el esfuerzo y no desperdiciarlo en lo que no merece la pena. Teniendo en cuenta que es muy difícil no desperdiciar porque si no fuera así siempre acertaríamos a la primera y eso no va a ser así. La economía del desperdicio se basa en partir de lo simple para a través del conocimiento generado y validado seguir creciendo.

No solo se trata del síndrome de la última versión sino que también nos lo encontramos en cualquier evolución del software (o en un desarrollo desde cero) cuando desde un principio se quiere tener una primera versión operativa del producto con demasiadas funcionalidades (digo demasiadas y no todas).

En mi opinión, la primera versión operativa debe tender hacia el menor número de funcionalidades necesarias, buscar el pragmatismo y la simplicidad aún a costa de tener una versión que tal vez no termine de satisfacer completamente al usuario (hay que tener en cuenta que, en cualquier caso, la decisión sobre la línea de desarrollo del producto recae en el usuario y de él dependerá hasta que punto se deja asesorar y qué considera como mínimo imprescindible).

A partir de esa versión toca iterar y seguir evolucionando el producto, siempre con la simplicidad como referencia.

¿Por qué lo simple como referencia? Porque es más sencillo llegar así hacia una solución más compleja, gracias al feedback obtenido por los usuarios y por el aprendizaje que se va obteniendo a todos los niveles mientras se desarrolla el producto y también porque en el caso de descubrir que el enfoque no es adecuado se ha desperdiciado menos esfuerzo en tareas que se podían haber evitado.

En el desarrollo de software lo simple gana. A veces se requieren soluciones que son inherentemente complejas, en ese caso nuestro objetivo será tratar de encontrar la versión más simple que la resuelva partiendo a su vez de porciones más simples.

Nos encontramos con sistemas de información que no terminan de ser efectivos o productivos para el usuario porque son demasiado complejos, ya sea a nivel funcional o de usabilidad.

Muchas veces he encontrado sistemas que aunque tratan de dar una solución desde lo simple, no lo consigue debido a las restricciones impuestas por una arquitectura o un diseño equivocado. Tenemos que tratar de evitar la imposición de restricciones que son perfectamente prescindibles.

Si pones restricciones técnicas que sea para tratar de obtener un valor que compense el coste que puede tener aplicarla en el proyecto, teniendo en cuenta que siempre se debe buscar el equilibirio.

Ya lo decía Winston Churchill: “Todas las grandes cosas son simples, y muchas pueden ser expresadas en una sola palabra”.

Decía Isaac Newton que “la verdad siempre se halla en la simplicidad y no en la multiplicidad y confusión de las cosas”.

Esta reflexión es muy aplicable al desarrollo de software.

Cuando se trata de implementar una funcionalidad compleja lo mejor es tratar de hacerlo de manera evolutiva. Vamos poco a poco, vamos a ir comprobando si realmente la idea es válida, de esta forma los ajustes serán más moderados y si es necesario desechar el camino andado y explorar otra alternativa los costes serán inferiores al de haber implementado completamente esa funcionalidad.

Sin embargo, esas prisas, en muchos casos fruto de la impaciencia y que no se corresponden con una necesidad real, dan lugar a que se trate de desarrollar de una sola vez una funcionalidad compleja, un subsistema o una aplicación. Otras veces es la propia metodología o estrategia aplicada la que te lleva a trabajar de esa manera.

Al final, si no se ha acertado tocará parchear, porque es fácil no acertar por la gran cantidad de variables que intervienen, entre otras: la especificación propuesta por el área usuaria no es correcta o los resultados de la misma no se corresponden a sus propias expectivas, errores en la propia especificación, mala interpretación de la misma por parte de los desarrolladores, mala selección de la arquitectura, errores de codificación, etc…

El parcheo es costoso y además no suele dar buenos resultados porque está muy condicionado por la solución anterior. Lo mejor en la mayoría de los casos suele ser rehacer, lo que sucede es que el propio estado del proyecto, con el producto en producción, utilizándose y con un presupuesto que no te permite hacer grandes alardes, te obliga a trabajar mediante parches.

En esta situación no se debe bajar los brazos y conformase. Considero necesario informar a quien corresponda de las consecuencias que tiene seguir trabajando de esa manera. No tienes garantías de que te hagan algo de caso, pero por lo menos lo habrás intentado y habrás abierto algo la puerta para que en el futuro cuando sigan existiendo problemas con el producto, que los habrá, puedas volver a intentarlo.