«Si el desarrollo de software es difícil, ¿por qué es difícil?»
En primer lugar, permítame decir que el desarrollo de software probablemente no es tan difícil como muchos otros campos. Sin embargo, es difícil, sólo que no en las formas que la gente que no está familiarizada con él realmente ve.
Los requisitos rara vez coinciden con la arquitectura interna del software
Eso no significa que la arquitectura o los requisitos estén mal. Significa que están utilizando diferentes vocabularios y diferentes abstracciones. Los requisitos especifican los comportamientos externamente visibles del software. Hay complejidad oculta en el interior.
Los clientes rara vez conocen todos los requisitos
Imagina que tienes que explicar a tu hijo cómo limpiar el suelo de la cocina. Es algo que has hecho muchas veces antes. Apenas tienes que pensar en los detalles. Le explicas todos los pasos y el niño se siente orgulloso de poder contribuir de forma útil. A la semana siguiente, te interrumpe mientras haces otra cosa el niño preguntando dónde está la escoba porque la semana pasada la sacaste al empezar la explicación y no le dijiste de dónde la sacaste.
Cada proyecto es único
No estás desarrollando Fun App 1.0 una y otra vez. Estás desarrollando Fun App 1.0, Fun App 1.1, Otra Fun App 2.0 (porque te uniste a ese proyecto después), Fun App para Windows 1.2, etc. Hay piezas que son iguales, y hay piezas que son únicas para cada proyecto. Las piezas que son iguales pueden ser el 80% del código. Son el 20% del esfuerzo. Pasas casi todo tu tiempo en las piezas que son diferentes.
Programar se trata de abstracciones e indirecciones
Para hacerlo efectivamente, generalmente tienes que ser capaz de mantener al menos tres vistas de algo en tu cabeza al mismo tiempo. Tienes que ver lo que está sucediendo desde el punto de vista de la persona que llama o el usuario de una abstracción. Necesitas ver lo que está sucediendo desde el punto de vista de la función llamada o de los internos de una clase que estás utilizando. Y necesitas verlo desde la perspectiva de lo que debería estar ocurriendo (si estás depurando) o lo que necesita ser implementado (si estás trabajando en una nueva funcionalidad).
Programar implica hacer un seguimiento del estado y del proceso
Se ha observado que uno de los obstáculos necesarios para aprender a programar del todo es entender el cambio en el estado del programa a lo largo del tiempo. Esto es, inicialmente, sólo comprender cómo las asignaciones cambian el valor de las variables. Con el tiempo, hay que ser capaz de seguir cómo cambia el estado mayor a medida que se ejecuta el código. Volviendo al punto anterior, una gran parte del esfuerzo está en ver qué invariantes deberían ser verdaderos entre las llamadas y hacer frente al hecho de que en medio de una llamada, el estado interno los viola porque el código no sólo se mueve atómicamente de un estado a otro.
Una gran parte de la programación es hacer cumplir las restricciones
Los modificadores de acceso, las declaraciones constantes, las convenciones de nombres, etc., son todas las restricciones que ponemos en nuestro código. Las restricciones normalmente no son ejecutables. Le dicen al compilador cosas que sabemos sobre el código, y limitan lo que podemos hacer. Para un principiante, parece que hacen el proceso más difícil, cuando en realidad permiten abordar problemas más grandes porque el código limita lo que tienes que pensar.
Mejores herramientas amplían el tamaño de los problemas que podemos abordar
Mejorar las herramientas no facilita nuestro trabajo. La dificultad se mantiene más o menos igual, y los problemas se hacen más grandes.