¿Cuáles son los principales malentendidos sobre el desarrollo de software?

Mito: la ingeniería de software consiste en diseñar la funcionalidad solicitada por el cliente . Esto está mal. La ingeniería del software se trata de equilibrar los requisitos explícitos (que llamamos funcionales ) con los requisitos implícitos (a veces llamados no funcionales ).

Estos requisitos implícitos generalmente incluyen:

• Requisitos operativos : cómo se realizará el mantenimiento y la resolución de problemas del software (en oposición a los usuarios finales). Ejemplo: los usuarios finales no se preocupan por los registros, pero si algo no cumple con sus expectativas, es mejor que haya implementado el registro, por lo que el soporte (que puede ser incluso usted mismo) puede encontrar lo que realmente sucedió. Del mismo modo, en el proceso de preparación de lanzamientos, ¿cómo puede demostrar que el software funciona y funcionará según las expectativas? Idealmente, debería haber proporcionado pruebas de regresión para esto.
• Requisitos de desarrollo : reconozca que es poco probable que el software que está escribiendo permanezca en la forma estática que lo lanzó y que cambiará con el tiempo después del lanzamiento inicial . En lugar de tratar de adivinar cuáles podrían ser estos cambios futuros (y codificarlos de inmediato), en su lugar codifica la funcionalidad mínima solicitada por el cliente ahora , para hacer que las futuras adiciones sean más fáciles y más robustas cuando se conocen . De manera similar, cuando se cambia el software, ¿cómo se asegura de que la funcionalidad existente no se rompa? Es por eso que debes hacerte una prueba unitaria . Finalmente, el código fuente existente generalmente lo leen los desarrolladores mucho, mucho más a menudo que lo que se escribe un nuevo código; intente minimizar el tiempo que esto consume haciéndolo legible .

Estas características implícitas deben diseñarse desde el momento (o incluso antes) cuando los clientes han expresado sus requisitos, ya que siempre es muy costoso agregarlos como una ocurrencia tardía. ¿Que caro? Dos ejemplos:

• El software lanzado sin las pruebas adecuadas puede llevar a la quiebra a una empresa. Si el software no está diseñado para pruebas, no se realizarán las pruebas adecuadas (es decir, exhaustivas).
• El software que es demasiado complejo o tiene demasiadas características especulativas puede ser más barato desechar y reemplazar, en lugar de ampliar.

Aquí hay muchas respuestas excelentes, ya que esta pregunta puede interpretarse de muchas maneras diferentes. Pero desde mi punto de vista, tendría que decir el mayor malentendido en el desarrollo de software a lo largo de los años, y particularmente hoy, especialmente cuando estamos tratando de refinar el ciclo ágil, acelerar el desarrollo rápido, los ciclos de velocidad, la programación de pares, los equipos ajustados , etc … es la brecha entre las necesidades / requisitos del cliente y la producción del equipo.

Hay una gran cantidad de cosas perdidas en la traducción cuando se discuten los requisitos. Reunión tras reunión se puede tener sobre estos temas. Comenzamos a hablar sobre el alcance del alcance y otras cosas. El mayor problema en el desarrollo de software en general es perder lo que el cliente realmente quiere o desea. Esto sucede de varias maneras:

1. Reuniones con las personas equivocadas. Ni siquiera son partes interesadas o personas que representan al cliente en absoluto.
2. Reuniones en el extranjero y con barreras idiomáticas o con equipos offshore donde hay una * tonelada * perdida en la traducción. No estoy afirmando que en alta mar no sean productivos, pueden ser geniales, pero me gustaría advertirles seriamente que requieren que tengan algo de piel en el juego, sean parte de su compañía (no solo contratados “sicarios”, por así decirlo), y que debe ser * MUY * claro sobre los requisitos, plazos, etc.
3. No hay un solo desarrollador o desarrollador principal o gerente técnico / tecnólogo en la sala cuando se discuten los requisitos. Este es un importante no no. Necesita a alguien que pueda al menos estimar a un alto nivel si estas cosas son posibles, dados los límites de tiempo y las preocupaciones monetarias.
4. Entra un nuevo gerente que no estaba en las reuniones originales y tiene su propia visión de cómo debería funcionar el producto. Pero no es lo que el usuario final realmente quiere (o necesita).
5. Demasiados chefs en la cocina. Esto sucede con demasiada frecuencia. Especialmente en compañías pequeñas y de nivel medio donde las personas intentan ser la próxima gran cosa o hacerse un nombre. Aquí es donde las cosas pueden * realmente * desordenarse. No puede tomar decisiones, se produce una sobrecarga de reunión, reunión tras reunión tras reunión, los requisitos cambian constantemente, incluso cuando no son necesarios, ni el cliente lo quiere, a veces se confunden en todas las reuniones y ni siquiera entienden de qué están hablando todas estas personas, ciertas personas comienzan a desconectarse, etc. Este es un desastre desagradable y no quieres que esto suceda. Probablemente sea lo peor de todo b / c cuando esto ocurre, básicamente un poco de todo lo anterior ocurre durante todo el proceso. El proyecto ahora, muy probablemente, está condenado. Y sucede con demasiada frecuencia, confía en mí.

El resultado final de cualquier proyecto de software debe ser entregar una aplicación de software, en cualquier forma que sea, cliente grueso o delgado, a una base de usuarios cuyas necesidades se satisfagan. Si puede hacer eso y puede hacerlo bien, puede exceder sus necesidades o hacer que su trabajo sea mejor, más fácil, más eficiente, entonces tendrá un producto exitoso incluso con desarrolladores mediocres. Una empresa, por encima de todo, necesita tratar de comprender qué es lo que realmente necesitan sus clientes o usuarios y satisfacer esa necesidad. Esto es lo que encuentro que se pierde con mayor frecuencia, especialmente en empresas pequeñas o medianas. La gran mayoría de la organización, en su conjunto (no necesariamente cada individuo o ciertos gerentes), realmente no obtienen lo que quieren o necesitan (o lo que sus clientes necesitan).

¿Por qué Google, Facebook o Microsoft tienen tanto éxito? ¿Youtube? ¿Y muchos otros que se han convertido en nombres conocidos? Porque construyen un producto, o conjunto de productos, que durante años ha respondido a las necesidades de las masas de una manera muy simple.

Uno de mis favoritos es este hecho por desarrolladores novatos que se aburren de compilar programas de consola y deciden tomar Unity y otros, estos:

estas aplicaciones de software no tienen el botón “hacer un juego increíble”.

Es un arte.

Recibo bloqueo de escritor con frecuencia. No importa cuánto lo intente, el código simplemente no vendrá. Estoy en una depresión y tener un gerente de cuello blanco respirando por mi cuello, volviéndome loco por objetivos poco realistas no ayuda de ninguna manera. Pero chico, cuando me pongo en marcha me pongo en marcha. Puedo producir código funcional que estará en el producto final en solo tres días más o menos y compensar el tiempo perdido durante la depresión.

Paypal es una aplicación y puedo clonarla por ti

Mire, cliente señor, Paypal no es solo una aplicación y si me arroja miles de dólares de bienvenida no podrá clonarlo en 30 días, no señor. La configuración del negocio, las licencias y la estructura web para todo el sistema solo le costará millones y si tuviera millones, no estaríamos hablando. No.

Puedo crear Facebook o Google

Jajaja. No, no puedes. Entre otras cosas, Facebook sucedió en el lugar correcto en el momento correcto con las personas adecuadas. Mi querido cliente, señor, aunque me haya dado el código fuente de Facebook, no podré clonarlo. De ninguna manera. Facebook es más que solo el software ahora. Es la experiencia y el conocimiento adquiridos por la empresa a lo largo de los años.

Linus lo hizo, yo también puedo crear mi propio sistema operativo

Primero, Linux no es un sistema operativo y segundo, ¿por qué, por qué? Si tiene el conocimiento, únase a la comunidad y contribuya, o impresione a MS y ellos lo comprarán o lo contratarán. Tus amigos codificadores solo dirán buen trabajo y eso es todo. No se convertirá en el próximo Ubuntu. Además, es tan difícil de hacer.

Trabajar en Google es lo más grande que puedes ser

Hay otros lugares y otros logros que puedes hacer. Si tienes la habilidad suficiente para llegar a Google, entonces tienes la habilidad suficiente para hacerlo solo y cambiar el mundo de alguna manera, y deberías hacerlo. Google es solo una empresa y eso es todo.

Esos son algunos de mis favoritos, creo.

Editar: es GNU / Linux, no Linux

Un comentario me corrige amablemente que es GNU / Linux y no solo Linux. Bueno, digo que si ese es el caso, entonces debería ser Apache / GNU / KDE / Mozilla / X.org / Linux para ser justos.

Uno que me quema regularmente es la expectativa de que este es un proceso lineal. Las personas con y sin experiencia se comportan regularmente como si el desarrollo de un sistema o una característica tuviera un inicio bien definido, un conjunto de pasos de implementación y luego se termina y nunca tenemos que tocarlo. Además de eso, los pasos de implementación se ven como si estuviéramos cocinando: haga las cosas del 1 al 50, cada uno lleva un tiempo que puede estimarse por adelantado y tratar de paralelizarlo para que se haga más rápido.

Nada podría estar más lejos de la verdad y la mayoría de los “abusadores” lo saben, por lo que agregamos algunas heurísticas, procesos, prácticas “ágiles” y mentiras honestas solo para poder brindar la certeza y previsiblemente que cada miembro de la junta directiva o nivel C pedir, porque, bueno, esa parece ser la única forma funcional de administrar un negocio en este momento.

Otra es que la calidad importa y es importante. Sin embargo, si los desarrolladores fueran ingenieros civiles o médicos, el 90% de nosotros ya habría sido encarcelado debido a los delitos que cometemos diariamente para cumplir con los plazos. Sorprendentemente, ese nivel de calidad todavía permite que las empresas que servimos operen y obtengan ganancias. Me sigue sorprendiendo esto.

Estimacion.

El desarrollador (s) piensa: ¿En serio? ¿Cómo podemos completar esto dentro del plazo?

El líder técnico (s) piensa: Genial. Se me ocurrió una estimación. Ahora, gran tarea de administrar (establecer expectativas para) desarrolladores, gerentes y clientes.

El gerente piensa: Ok. Equipo, quiero que estén orientados a objetivos. Necesitamos entregar dentro del plazo. Teniendo en cuenta la estimación, conectemos semanalmente una vez para rastrear el estado. Espere. No. Vamos a conectarnos diariamente una vez. Espere. No. Vamos a conectarnos cada hora una vez. Espere. No…

El cliente piensa: Queremos cambiar ligeramente el requisito. Esperamos que no afecte los plazos.

De hecho,

Fuente de la imagen: Google Images.

Foto de Christopher Gower en Unsplash

Solo para reiterar algunas otras excelentes respuestas …

El mayor malentendido sobre el desarrollo de software es que el alcance es de alguna manera definible y una cantidad conocida con una duración y un costo.

Esto probablemente se puede decir sobre cualquier cosa personalizada que no se fabrique de manera repetible también.

Un gran malentendido que veo con respecto a los servicios de desarrollo:

Los proveedores de servicios no entregan productos, sino que entregan tiempo. Esto debería ser obvio cuando se contrata con una empresa de servicios, pero parece que no.

Esto probablemente se puede decir sobre cualquier industria de servicios con resultados tangibles (como una empresa de remodelación de cocinas). El concepto de tiempo de compra solo parece entenderse completamente en ciertas situaciones, como los acuerdos de consultoría comercial y los asesores legales.

Algunos de los detalles que se derivan de los malentendidos:

1. Los requisitos no se pueden escribir de manera que todas las partes entiendan de la misma manera. Todos los que leen los requisitos visualizan su implementación de manera diferente.
2. Las incógnitas, de las cuales hay muchas, no pueden ser conocidas por adivinanzas experimentadas. Los grandes proyectos tienen más incógnitas, por lo que se debe suponer que los excesos presupuestarios aumentan con el tamaño del presupuesto.
3. El proveedor de servicios no se arriesga y no obtiene recompensas adicionales. Todos los riesgos y recompensas recaen en el propietario del software.

Veo un mundo donde los contratos de software evolucionan para eliminar estos malentendidos. Lea sobre eso aquí:

El pequeño secreto sucio de tu desarrollador

Diviértete y {create: awesome}

Como alguien más ya mencionó, el error más grande es que el desarrollo de software es fácil .

Usted ve este malentendido de nuevas empresas nuevas, gerentes no técnicos, personal de ventas y marketing de su empresa y sus amigos con las próximas ideas de mil millones de dólares.

En mi opinión, este es el trabajo más difícil, y cada vez es más difícil ya que los requisitos del software se vuelven cada vez más complejos con el tiempo y los expertos de este dominio son pocos. El desarrollo de software en sí mismo puede no ser tan difícil, pero hacerlo bien es lo que distingue a un desarrollador bueno y no tan bueno.

Si fuera fácil, los desarrolladores de software no recibirán salarios tan altos, y habría desarrolladores de software en todas partes. En realidad, buena suerte para encontrar buenos desarrolladores de software. Las empresas tienen que robarse unas a otras, porque los buenos desarrolladores de software no están libres y buscan trabajo.

Debido a que esta es una industria relativamente nueva y la demanda explosiva de buenos desarrolladores de software es reciente, muchas compañías aún aprenden este hecho de la manera difícil. Esto tampoco excluye a muchas grandes empresas, que subcontratan su trabajo a desarrolladores ‘no desarrolladores’ solo para saber más tarde que realmente necesitaban encontrar desarrolladores reales, que simplemente no están disponibles en el mercado.

Sin embargo, habiendo dicho todo esto, animo a las personas a que entren en este campo y trabajen duro, su futuro estará seguro y garantizado. Siempre estamos buscando buenos desarrolladores y parece que no podemos encontrarlos.

Agregaré algunos más:

1. Los objetivos y la funcionalidad no se pueden especificar antes de la codificación.
2. La estructura y la disciplina no son tan importantes como lo serían en la construcción de un puente, automóvil o reactor.
3. No hay tiempo para probar, además no tenemos
4. Los errores son inevitables (hasta cierto punto, esto es cierto, pero de ninguna manera cerca de lo que se publica y se tolera en estos días)
5. La apariencia de la interfaz de usuario no importa (creo que esto está comenzando a cambiar rápidamente a medida que las generaciones mayores se retiran gradualmente, las personas más jóvenes están acostumbradas a buenas interfaces)

La cantidad de optimismo sin sentido en el desarrollo de software es alucinante. Hay libros completos dedicados a compensarlo. Principalmente trabajo con software en un entorno industrial, donde, en mi opinión, la calidad debería conducir a la innovación de características (quiero que mi energía y mi agua funcionen siempre).

Aquí hay algunos malentendidos sobre el desarrollo de software:

• Elegir la tecnología / metodología / lenguajes / herramientas / etc. correcta es importante / crucial. La mayoría de los problemas se pueden resolver de muchas maneras diferentes y casi nunca hay una “forma correcta” unánime de hacerlo. Lo que es más importante es elegir algo con lo que los desarrolladores de software se sientan cómodos y con experiencia.
• Las tareas simples serán rápidas de implementar. Algo que parece, suena o parece muy simple no puede llevar días o semanas para implementarse en el software, ¿verdad? Sí puede. El diablo realmente está en los detalles del desarrollo de software y siempre te sorprenderá algo. Y generalmente no está relacionado con la escritura real del software.
• Comenzar desde cero será mejor que arreglar algo roto. La complejidad generalmente existe porque algo es complejo, no porque los desarrolladores que lo escribieron sean malos desarrolladores. Sí, probablemente terminará con una solución “mejor” si comienza desde cero, pero tenga la seguridad de que tomará mucho más tiempo del previsto, especialmente si necesita replicar todas las características del sistema que está intentando reemplazar.

El desarrollo de software es escribir código. Una pequeña parte es cierta, pero la mayor parte del desarrollo de software es planificación, modelado, reuniones de partes interesadas, investigación, depuración, refactorización, etc.

El desarrollo de software es un proceso lineal. No, mal. Un poco como hacer una película donde puedes filmar el final al comienzo del rodaje y luego ‘rebotar’ alrededor del guión filmando cosas fuera de secuencia, el desarrollo de Softare solo parece lineal para los extraños que miran el producto terminado.

El desarrollo de software es algo muy difícil de hacer. Err, no, en realidad no, de lo contrario no lo estaría haciendo. Como la mayoría de las profesiones, es algo difícil de hacer en el extremo afilado. Aquellos desarrolladores que escriben lenguajes y marcos para AI y crean casos de uso verdaderamente nuevos, están haciendo cosas que son muy difíciles de hacer. El resto de nosotros nos paramos sobre sus hombros.

Esos son mis tres primeros.

Ese desarrollo de software tiene mucho que ver con la programación.

El desarrollo de software se trata de resolver problemas y diseñar software (estructuras de datos, algoritmos, flujos de control). La programación es simplemente una herramienta para convertir un diseño en algo que se ejecute.

Por analogía con la ebanistería o la construcción de viviendas: las tablas de cortar, clavar martillos y girar los tornillos es lo último que hace, después de diseñar el gabinete o la casa. (Bueno, técnicamente, hay inspección, o para software, prueba y empaque).

OK, aquí vamos Moray’s RANT OF THE WEEK …

Algoritmo de desafíos

Mucha gente piensa que el desarrollo de software se trata de ‘descifrar’ un algoritmo, un desafío técnico desafiante. No es. Se trata de construir software.

Si usa macOS, mire las aplicaciones en su Dock, si usa Windows, mire … como sea que lo llamen ahora. Esas aplicaciones en dock / thingie, ese es el trabajo. Eso es lo que tienes que hacer.

El desarrollo de software se trata de hacer productos , su capacidad en TopCoder o lo que sea irrelevante.

Es mejor hacerlo en código

“Los profesionales no usan Interface Builder”. Bullshit, los profesionales usan la mejor herramienta para el trabajo, y ese es Interface Builder. Raramente es mejor hacerlo en código.

Se necesita un equipo para construir software

No, puedes hacerlo tú mismo. Hay muchas grandes aplicaciones comerciales que fueron desarrolladas por un solo individuo .

• Hay un dicho entre los desarrolladores de software que “1 mujer puede tener un bebé en 9 meses, no significa que 9 mujeres puedan tener un bebé en 1 mes”. Lo mismo es aplicable para el desarrollo de software.
• He visto a los gerentes o propietarios de productos preguntar por qué tiene que tomar 1 semana por 2 días de trabajo. Y la respuesta es, escribimos pruebas, nos aseguramos de que la complejidad ciclomática del código sea menor, refactorice donde sea necesario, necesite implementar y probar, etc. Simplemente no se trata del código, la codificación es la parte fácil.
• Se considera que una vez que se corrige el error, debe implementarse en producción de inmediato. Ese no es el caso. Necesita ser probado en QA o puesta en escena. Y el error puede o no ser parte de un sprint y puede implementarse al final del sprint, dependiendo de la metodología que siga.

Que el costo a largo plazo de cortar esquinas tiene una variación proporcional al “tamaño” de las esquinas que se cortan.

Reformulando esto como una observación: el costo a largo plazo de los recortes tiene, de hecho, una variación increíblemente enorme.

Las esquinas deberían cortarse cuando deberían y no deberían cuando no deberían . En muchos casos, un ingeniero experimentado que se siente diferente sobre el costo a largo plazo de una solicitud de reducción es anulado, siendo “solo un ingeniero que no entiende de negocios”. En otros casos, los ingenieros pueden ser sobreprotectores sobre la perfección de su código y la intuición del gerente de que el negocio no se vería afectado es correcta.

Sin embargo, el primer caso es el más interesante, debido a la diferencia de costos: cuando el ingeniero se equivoca, la compañía perdería algo de tiempo de ingeniería (que aún puede ser crítico en algunos casos raros). Cuando el ingeniero tenía razón sobre el costo a largo plazo, esto solo se dio cuenta demasiado tarde, y el costo puede ser desproporcionado a la decisión aparentemente menor que había salido mal.

Un ejemplo clásico sería un gerente que, bajo presión de plazo, decide aflojar la cobertura de la prueba. En un escenario, el producto es un servicio web que puede experimentar una breve interrupción debido a un error no detectado. En un escenario extremo, el producto podría ser una pieza de hardware producida en masa que necesita ser retirada debido a ese error que podría haber sido expuesto por las pruebas comprometidas.

Desarrollo de software un campo bastante candente hoy en día. Así que también surgen algunos mitos. Resumo algunos de ellos como

1. Paquetes altos: Todos piensan que cada ingeniero de software obtiene el paquete alto.
2. El desarrollador de software también conoce el hardware: un programador no es un técnico de reparación de PC, simplemente nadie parece recordarlo.
3. Seleccionar en Google es el objetivo final de la vida: cada programador de software cree que trabajar es lo más alto que puede lograr. Pero eso no es verdad.

Grandes malentendidos:

1.) Que lo que aprendiste en los estudios de CS valdrá mucho en una codificación para un entorno empresarial. – La mayoría de las empresas solo desean un funcionamiento rápido y funcional sin preocuparse por los patrones de diseño y la arquitectura. No quiere decir que algunas compañías no enfatizan los patrones de diseño y el buen diseño arquitectónico. La mayoría solo quiere que sus datos se definan.

2.) Que las necesidades de un usuario son una solución rápida: a muchos usuarios les encanta hablar sobre su rápida adición o cambio. No tienen idea de cómo un pequeño cambio llamado tiene grandes efectos y posiblemente consecuencias para la arquitectura de la aplicación. Usted encuentra que eso es cierto en bases de código maduras masivas.

Estoy seguro de que hay muchos otros malentendidos, pero estos son los dos con los que me encuentro con frecuencia.

• Los desarrolladores de software son buenos en matemáticas. Bueno, no, la mayoría de nosotros no hemos tenido que usar ninguna matemática en años.
• Los desarrolladores de software son tímidos / antisociales / introvertidos. Francamente, la mayoría de los desarrolladores de software que conozco son DEMASIADOS sociales. Es todo lo que hacen: ser social todo el tiempo, en una gran variedad de formas
• Los desarrolladores de software pueden reparar computadoras o piratear cuentas de Facebook. No, el primer trabajo es para administradores de sistemas y personal de hardware y el segundo es para hackers dedicados

Falta considerar el factor humano.

Se supone que debo grabar mis vacaciones (entre otras) en una plataforma gigantesca. Excepto que la plataforma no está disponible en 4 días de 5: para el cálculo de la nómina (no, no es una broma), para pruebas de recuperación de respaldo (no es una broma tampoco), porque el sistema está caído por alguna razón inexplicable … La broma aquí es que debe obtener un ticket de soporte el día en que pueda conectarse al sistema. El día que logré registrar unas vacaciones, mi supervisor se metió en mi oficina para explicarme que la solicitud se enviaba al buzón de correo del gerente, quien inmediatamente le preguntó a mi supervisor qué estaba sucediendo. Se me solicitó amablemente enviar un correo antes de cualquier futuro que intente usar el sistema.

La razón de esta falla es que el sistema era una aplicación de arriba hacia abajo de la compañía de software superior y de alta gerencia (una de las 10 principales) sin pensar en los usuarios finales. Resultó en un conjunto totalmente inestable de pantallas desagradables y desagradables para el usuario, que nadie quiere usar y los empleados en el mejor de los casos boicotean y en el peor intentan sabotear.

La moral es que si quieres buenos datos, debes proporcionarles un sistema que sea fácil y divertido de usar, los usuarios nunca deben sentir que intentas usar los datos para reunirlos y tu sistema debe proporcionar un valor agregado al formato formal actual. y prácticas informales. En estas condiciones, con una comercialización constante y una explicación de por qué utiliza los datos, puede tener la oportunidad de utilizar el sistema. Y datos realistas para entrar.

Que puedo decirte cuánto tiempo llevará

No puedo, pero adivina qué, nadie más puede hacerlo. No significa que soy malo en mi trabajo, solo significa que estoy siendo honesto. Es posible que pueda encontrar a alguien que le dé una respuesta, pero será tan preciso como predecir una tormenta con seis meses de anticipación. Algunas razones por las que no puedo decirte cuánto tiempo llevará:

1. Sus requisitos son extremadamente vagos e incompletos.
2. Sus requisitos están completos, pero cerca del final se dará cuenta de que no reflejan lo que realmente quiere y nos hubiera ido mejor con el escenario 1 e inventando todo en el camino.
3. El desarrollo de software es un arte, y como una pintura o escultura, nunca he creado este antes. No es pintar por números.

De hecho, he descubierto que los proyectos abiertos mal definidos a menudo tienen un resultado final muy bueno porque las personas presentan ideas creativas en el camino después de ver la dirección en que van las cosas. Sin embargo, este no será un enfoque aceptable en un entorno grande, porque se deben planificar y asignar muchos recursos. No soy indiferente a las necesidades del lado comercial de las cosas, pero el simple hecho de tener que convertir una función artística en una función comercial no significa que vaya a funcionar sin problemas. Creo que lo mejor que puede hacer es esperar silenciosamente que los grandes proyectos demoren más de lo estimado y planear enfrentarlos.

Que cualquier programador puede hacer cualquier cosa que cualquier otro programador pueda hacer

De nuevo, esto es un arte. El talento o la falta del mismo es extremadamente amplio. Tienes estrellas de rock, tienes el equivalente de los rechazos de American Idol y todo lo demás. A veces, un codificador de estrellas de rock puede ser más difícil de manejar (por ejemplo: es obvio sobre la mejor manera de hacer las cosas), pero puede valer la pena el esfuerzo adicional para otorgarles algo de libertad adicional al final.

Uno o dos desarrolladores pueden replicar alguna característica de software que haya visto implementada por Google o Apple

Google y Apple tienen grandes recursos a su disposición y muchas de las cosas que desarrollan involucran equipos interdisciplinarios y requieren una infraestructura de hardware masiva en el back-end. Sé que es genial que Google ya le muestre una página de resultados de búsqueda antes de que termine de escribir los términos de búsqueda completos, pero no, no puede hacerlo con un desarrollador y una granja de VMware x86 de rango medio.