Entorno de desarrollo de software versus interno [cerrado]

Según mi experiencia, la distinción que hace entre "en casa" y "producto distribuible" es falsa.

Hay empresas que toman en serio su proceso de desarrollo de software y aquellas que no lo hacen. Si están "en casa" o "a medida" o "envoltura retráctil" tienden a no aparecer tanto (aunque si son proveedores de "envoltura retractil", si no tienen un proceso probablemente no estarán en el negocio para largo).

Debe buscar un lugar que tenga los estándares de desarrollo que está buscando. Al entrevistar, debe hacer estas preguntas para asegurarse de que el lugar sea de su agrado a este respecto (así como a otros).

Puedes leer este artículo

enlace

de Joel Spolsky, que trata exactamente tu pregunta.

Estoy en una posición en la que tuve que trabajar en los dos últimos años: se vendió un producto de software de tamaño mediano y algunos software interno. Desde esa experiencia, puedo decirles que hay diferencias entre esas dos plataformas, pero la situación no es tan mala como Joel lo describió.

Por ejemplo, la mayoría de nuestro software interno debe ejecutarse solo en un entorno muy restringido. Muchas herramientas solo funcionan con una determinada hoja de cálculo o una versión de base de datos, con un entorno de red específico, con un número restringido de usuarios, sin necesidad de rutinas de instalación, etc. Nuestro producto de envío. Por otro lado, eso no significa que mi código para los programas "internos" tenga una calidad inferior o esté escrito de una manera más "casual".

Hace mucho tiempo, leí un libro sobre Agile Project Management (me gustaría poder recordar el título), donde el autor distinguió los sistemas según sus niveles de tolerancia para los defectos del sistema. La tolerancia para los defectos puede variar desde muy alta, por ejemplo, una utilidad utilizada por otros desarrolladores (donde los errores son simplemente un inconveniente), hasta muy baja, por ejemplo, un sistema que está ejecutando soporte vital para los astronautas (donde un error podría poner en peligro la vida).

El punto del autor era que la metodología de desarrollo (y la formalidad) debían ser ajustadas a la tolerancia a fallos (o criticidad) del sistema. Creo que esta distinción es la más importante, en lugar de distinguir entre el desarrollo interno y el software para la distribución general.

Imagine un hospital que tiene desarrolladores internos que construyen sistemas de registros médicos que podrían afectar la calidad de la atención médica. En este caso, es probable que la tienda interna sea más rigurosa que una consultora del sitio web, que está creando productos web para ser utilizados por el público en general.

He trabajado para empresas de software, agencias de marketing, telefonía móvil y bancos, una cosa que diré, es la cultura y la industria de la empresa que dictan el nivel de los procesos aplicados. El entorno más riguroso, lento, restrictivo y probado que he experimentado fue el desarrollo interno de un banco. Lo más casual fue una agencia de marketing.

Recomiendo aprender de esta experiencia y utilizarla para decidir su dirección futura para su próximo trabajo. La industria del desarrollo de software no es una ciencia, su arte / ciencia, por lo tanto, la variación y las diferencias de una compañía a otra. Es más importante que aprendas a hacer las cosas bien con respecto a tu código. Aunque hacer una nota mental de las fallas o la falta de procesos es útil, así que cuando su gerente pueda implementar procesos mejores.