¿Cómo explicaría que la ingeniería de software es más especializada que otros campos de ingeniería? [cerrado]

9

Trabajo con alguien que insiste en que cualquier buen ingeniero de software puede desarrollar cualquier tecnología de software, y la experiencia en una tecnología en particular no importa para construir un buen software. Su analogía fue que no es necesario tener conocimiento del producto que se está construyendo para saber cómo construir una línea de ensamblaje que fabrique dicho producto.

En cierto modo, es un cumplido ser visto con un ojo tal que "si eres bueno, eres bueno en todo", pero de alguna manera también trivializa la profesión, como en "Codemonkey, vaya código de honda". Sin experiencia en ciertos marcos de software, puede meterse en problemas rápidamente, y eso es importante.

Traté de explicar esto, pero él no lo compró. ¿Alguna opinión o pensamiento diferente sobre esto para ayudar a explicar que mi experiencia en una cosa no se traduce en todas las cosas?

engineering

— Spencer Kormos
fuente

77

Si vas a votar en contra, ¿podrías al menos comentar por qué? Particularmente porque su entrada podría ayudar a reformular / reenfocar la pregunta.

— Spencer Kormos

11

En primer lugar, esto es una diatriba y no una pregunta, y en segundo lugar, es una diatriba defectuosa, esto debe ser rechazado y cerrado.

66

@JarrodRoberson Hay una pregunta legítima aquí, creo. Pide una buena explicación que pide una explicación de por qué algunos ven la ingeniería de software como más o menos especializada que otros campos de ingeniería.

— maple_shaft

77

@SpencerK Tu pregunta es "algún tipo al azar hizo una mala analogía, cómo respondo", y bueno, esa no es realmente una pregunta. Solo solicite evidencia sólida y / o referencias que respalden su posición, usted no es el que necesita probarse aquí.

— Yannis

55

-1 porque no estoy de acuerdo con tu premisa. La ingeniería de software no es más especializada que otros campos de ingeniería. Ambos pueden ser altamente especializados y generalizados. Un buen ingeniero electromecánico puede no ser un buen ingeniero biomédico. Por otro lado, un buen electricista podría trabajar tanto en casas como en automóviles.

— zzzzBov

23

pero en cierto modo también trivializa la profesión, como en "Codemonkey, vaya código de honda".

Yo diría todo lo contrario. Un buen ingeniero de software tendría la capacidad de conceptualizar, diseñar y diseñar software de calidad independiente de la tecnología. El extremo opuesto de este espectro es la "clave de código" de .NET o Java o PHP que es buena para recibir instrucciones o especificaciones y utilizar la herramienta para implementar el software.

Un ingeniero de software no necesita ser un maestro de todas las herramientas, pero debe tener un buen conocimiento de alto nivel sobre cuáles son la mayoría de ellas, qué aportan a la mesa y lo que probablemente sea más apropiado para el proyecto dado. . Esperaría que un mono de código solo fuera un maestro de su reconocida experiencia en una herramienta específica.

No confiaría en un ingeniero de Ford que no sabe cómo hacer el trabajo del mecánico.

Sin embargo, la ingeniería de software es uno de estos campos donde, en muchos casos, se espera que seamos el ingeniero, el constructor y el mecánico, todo al mismo tiempo.

— árbol de arce
fuente

8

También destacaría la importancia de comprender los conceptos y principios sobre los idiomas y las herramientas.

— Oded

+1 Una de mis manías son las personas que dicen "Soy un desarrollador de C # ...". Y luego solo bebe el kool-aid y acepta cualquier cosa de la EM como gospel. 10 años de programación. Aprendí más de 11 lenguajes de programación, y cada uno ha realizado mejoras masivas en la forma en que programo en los otros lenguajes. ¡Aprende ingeniería de software! No plataformas que se habrán ido en 2 años.

— Timothy Baldridge el

+1 para referencia del ingeniero de Ford. No había pensado en Ingenieros de Software vs Programadores de esa manera antes.

— Dalin Seivewright

Un programador es un subconjunto de un ingeniero, no al revés.

— Spencer Rathbun

11

Estoy de acuerdo con la persona con la que trabaja. Un buen ingeniero de software se ocupa de los principios generales de diseño y producción de software. Los lenguajes y marcos reales son detalles.

Eso no es para trivializar la facilidad con la que puede elegir nuevos lenguajes y marcos. Siempre hay una curva de aprendizaje asociada con ellos, pero el punto es que es una curva, no una pared vertical para un buen ingeniero de software.

Un buen ingeniero de software tiene una amplia experiencia en varias herramientas y tecnologías diferentes. Si no lo hace, ¿cómo puede elegir la mejor herramienta para el trabajo? Para eliminar el viejo cliché, para un hombre que sabe cómo usar un martillo, cada problema parece un clavo. Incluso si no eres un experto con un destornillador, vale la pena tener una comprensión pasajera de ellos para que puedas reconocer un tornillo no solo como un clavo de aspecto divertido.

— JeremyP
fuente

"Un buen ingeniero de software se ocupa de los principios generales de diseño y producción de software". Producir sistemas de control integrados y aplicaciones web son casi exactamente iguales , ¿verdad?

— Marcin

@ Marcin: Algunos de los principios son, sí. El punto que estaba haciendo es que (por ejemplo) diseñar un sistema embebido en C o ensamblador emplea el mismo tipo de principios a pesar de que las herramientas son diferentes.

— JeremyP

Esas herramientas no son tan diferentes y abordan dominios con problemas muy similares. Es por eso que esto es completamente inútil.

— Marcin

1

@Marcin: obviamente no ha programado en ensamblador o no está programado en C. Le aseguro que a pesar del mito común, C no es ensamblador y la programación en esas herramientas es tan diferente como (digamos) la programación en C y Ruby.

— JeremyP

1

@Marcin, claro, y los bolos son solo cuestión de derribar todos los pines. Pedazo de pastel realmente. Si bien la programación web y la programación integrada pueden compartir algunos principios de alto nivel y mejores prácticas, lo que realmente gobierna el trabajo diario son las restricciones que rigen la implementación de esas prácticas. Si bien es posible que pueda volver a capacitar a un programador web como ingeniero integrado y viceversa, no son fungibles.

— Charles E. Grant

5

Versión TLDR: otras disciplinas de ingeniería necesitan conocer los materiales que están utilizando (por ejemplo, los arquitectos necesitan saber cuánta carga pueden soportar los materiales que están utilizando en su diseño ). Los lenguajes y marcos que utilizamos para la ingeniería de software tienen ciertos límites y debemos estar familiarizados con ellos para diseñarlos y desarrollarlos de manera efectiva.

Hay dos fases distintas de lo que hacemos. El primero es el diseño conceptual. Es un diseño de sistema de alto y bajo nivel (por ejemplo, usando UML). Los diseños de alto nivel pueden ser teóricamente independientes de la implementación (aunque a veces un diseño de alto nivel tiene que tener en cuenta detalles específicos, como la plataforma de la base de datos, el middleware estándar, etc.). Los diseños de bajo nivel son un poco más complicados. Puede diseñar los detalles de la lógica empresarial sin incluir los detalles de la infraestructura y, una vez más, en teoría, estos pueden ser independientes de la plataforma.

La segunda fase es la programación real. Mientras que algunos ven la programación como construcción, otros (incluyéndome a mí) argumentan que la codificación sigue siendo una disciplina de diseño (en PPP , Bob Martin se refiere a un artículo en el que el autor presenta un muy buen argumento en este sentido, no lo tengo con ahora, pero actualizaré esta respuesta con un enlace a ese artículo). La construcción real ocurre cuando presionas compilar y en efecto es gratis.

Al igual que un arquitecto tiene que tener en cuenta cosas como la resistencia a la tracción y a la compresión de los materiales de construcción que está utilizando, el ingeniero de software debe conocer las capacidades de la plataforma en la que se está desarrollando al escribir código. Yo diría que un diseño de sistema de bajo nivel no es muy efectivo si no tiene en cuenta las opciones de plataforma también.

— Michael Brown
fuente

5

Como alguien que se graduó de un programa de grado de Ingeniería de Software, puedo decir que su compañero de trabajo es parcialmente correcto. Un buen ingeniero de software se enfoca en aplicar matemática, estadística, informática y experiencia en el dominio para construir un sistema. Los métodos que utiliza un ingeniero de software suelen ser independientes de la tecnología y el lenguaje: las herramientas no importan tanto como los principios subyacentes.

Dicho eso, la analogía de tu compañero de trabajo es defectuosa. Comprender los problemas del dominio es esencial para cualquier disciplina de ingeniería. Si no comprende completamente el problema que está tratando de resolver y las personas que está tratando de satisfacer, se vuelve infinitamente más difícil construir la mejor solución posible a sus problemas.

En última instancia, la ingeniería de software (y cualquier disciplina de ingeniería) se trata de aplicar una serie de conceptos para resolver un problema. Si usa con frecuencia las mismas herramientas, se volverá más competente con esas herramientas. Será más fácil para usted identificar los problemas que esas herramientas pueden resolver, los riesgos o dificultades con el uso de esas herramientas, y luego usar esas herramientas para construir una solución.

— Thomas Owens
fuente

Los principios subyacentes pueden variar enormemente.

— Marcin

1

@ Marcin No, no lo hacen. La informática no cambia si las tecnologías cambian. Las matemáticas no cambian. Las estadísticas no cambian. Tampoco el análisis de requisitos, el diseño del sistema, las prácticas de gestión de la configuración, las estrategias de verificación y validación, los principios de calidad ...

— Thomas Owens

En realidad, "el análisis de requisitos, el diseño del sistema, las prácticas de gestión de la configuración, las estrategias de verificación y validación, los principios de calidad" cambian todo entre dominios problemáticos. Si no lo reconoce, es probable que haga un trabajo muy, muy pobre trabajando en un dominio que no conoce, porque es demasiado arrogante para darse cuenta de lo que no sabe. Además, las matemáticas aplicables cambian bastante, pero apuesto a que te imaginas que también sabes todo sobre las matemáticas.

— Marcin

@ Marcin He trabajado en todo, desde sistemas integrados hasta aplicaciones web. No cambian mucho. Las cualidades de un buen requisito no cambian según el dominio. Las herramientas utilizadas para diseñar un sistema no cambian. La forma en que mide y logra sistemas de alta calidad no cambia.

— Thomas Owens

1

Sí, tiene razón, cada proyecto de software en el mundo es el mismo, y ha descubierto cómo administrar cada proyecto. Probablemente debería escribir un libro explicando la única forma verdadera de escribir y administrar todo el software.

— Marcin

4

Su analogía fue que no es necesario tener conocimiento del producto que se está construyendo para saber cómo construir una línea de ensamblaje que fabrique dicho producto.

Esto es casi seguro que es incorrecto. Los ingenieros de producción especializados deben comprender bastante acerca de los productos bajo su cuidado.

En cualquier caso, una mejor analogía es con los graduados de cursos de ingeniería mecánica: a pesar de que todos comienzan (tanto en mech como en software) con las mismas habilidades, nadie sigue siendo "un ingeniero mecánico", sino que se especializa en los tipos de cosas que construyen. Del mismo modo, el desarrollo de software también tiene subcampos muy distintos.

Para volver a la analogía de la línea de ensamblaje, cada línea de ensamblaje es diferente para cada producto, y los diferentes tipos de desarrollo de software requieren diferentes metodologías: no construiría su software de seguridad de la misma manera que construye un juego.

— Marcin
fuente

1

La construcción de software al mismo nivel es la misma independientemente del producto de software. Simplemente los llamamos metodologías en lugar de líneas de ensamblaje , pero conceptualmente son lo mismo.

1

@JarrodRoberson No. Las líneas de ensamblaje no son uniformes, y las metodologías generalmente no son aplicables.

— Marcin

2

Estoy de acuerdo con Marcin, debes tener conocimiento de un producto para poder armar una línea de ensamblaje para el producto. Debe poder seleccionar con precisión las herramientas que se utilizarán para obtener el resultado final correcto. En software, una metodología sería una herramienta o tarea específica. Si su única tarea es completar una tarea específica, es posible que no necesite conocer el conjunto. Pero entonces eres un operador y no un ingeniero. Seleccionar el conjunto correcto de metodologías para formar la línea de ensamblaje lo convierte en un ingeniero como cualquier otra ingeniería. No es más especializado o diferente.

— RJay75

2

Hay una curva de aprendizaje involucrada con diferentes especializaciones. Estoy hablando de las diferencias entre la programación integrada / en tiempo real, la programación de aplicaciones web, la programación de sistemas / sistemas operativos, la programación de clientes gruesos, el desarrollo móvil, etc.

Alguien que sea experto en un tipo de programación podría no ser capaz de cruzar a otro de inmediato debido a diferentes requisitos. Claro, un ingeniero de software tiene lo básico para hacerlo, pero lleva tiempo especializarse en algo.

— Atif
fuente

1

Estoy de acuerdo con la premisa que sugiere su colega, aunque agregaría una advertencia.

Un buen ingeniero de software podrá construir un buen software en cualquier tecnología ... después de haber aprendido un poco en la nueva tecnología.

Puede haber algunas peculiaridades que no son obvias al principio, pero un buen ingeniero de software pronto las aprenderá.

Creo que lo que realmente quiere decir es que solo porque un desarrollador tenga 2 años de experiencia sólida en C #, no significa que sea un mejor ingeniero de software con experiencia en Java, que nunca antes haya hecho C #, que no pueda venir, aprender C # y rápidamente convertirse en un mejor desarrollador de C # que el primer chico.

En otras palabras, no necesariamente debes descartar al chico Java por un trabajo, SOLO porque él ha "cumplido" en C #.

— ozz
fuente

Creo que esto es un hecho, pero realmente se trata de ROI. No contrataría a un ingeniero con experiencia primaria en Java si quisiera obtener un proyecto C ++ en 6 meses. Sin embargo, si tiene un proyecto Swing que necesita salir en 6 meses, un ingeniero primario del lado del servidor aún podría calificar.

— Spencer Kormos

@SpencerK absolutamente de acuerdo. Depende de cuán rápido necesite su ROI. Si tiene un período más largo de espera, entonces el mejor ingeniero de software debería "ganar".

— ozz

Además, menos duro si fue usted!

— ozz

1

No, yo no. No hago voto negativo sin comentar por qué. Tengo mejores modales que eso!

— Spencer Kormos

1

Caso en cuestión: el marco de software con el que usted siente que es tan crítico para tener experiencia especializada probablemente no existía hace 10 años, o ha sufrido una transformación significativa si lo hizo. La naturaleza misma de nuestra profesión hace que sea imposible especializarse para la totalidad de la carrera. Dependiendo de sus respectivos niveles de habilidad, su especialización le brinda una ventaja de entre 1 y 6 meses sobre alguien que nunca ha usado su marco particular. Después de eso, estás a la par.

— Karl Bielefeldt
fuente

2

De Verdad? Supongo que esperarías que un ingeniero de seguridad esté listo y codificando juegos en 6 meses, y no se pueda distinguir de un especialista experimentado.

— Marcin

Estoy de acuerdo con Marcin, no es solo el conocimiento de un lenguaje de programación o plataforma. He trabajado en dos áreas diferentes y he pasado algunos años en cada una de ellas: lleva un tiempo hasta que esté lo suficientemente familiarizado para ser realmente profesional y productivo en un área. Por supuesto, ser un especialista en software experimentado acelera las cosas, pero creo que 2, 3 años en lugar de 6 meses.

— Giorgio

1

Trabajo para una compañía de helicópteros y los ingenieros de aviación aquí están especializados en los tipos de aviones con los que pueden trabajar. Deben ser "tipo clasificado". Técnicamente, podrían trabajar en cualquier cosa, desde un Robinson R22 a un Jumbo Jet, pero no sin el entrenamiento de conversión.

Creo que esto es bastante similar a la ingeniería de software, excepto que el "entrenamiento de conversión" es más informal para los ingenieros de software.

— Jaydee
fuente

1

Al hablar con un pintor, ¿le dirías que no tendría problemas para esculpir?

Aprender un nuevo idioma o detalles específicos de un nuevo dominio es similar a un artista que se ocupa principalmente del lápiz y la tinta y aprende a pintar (o viceversa). De esto es de lo que hablan la mayoría de las otras respuestas, de cómo su amigo está parcialmente correcto: se aplican muchos de los mismos conceptos.

Pero enseñarle a un pintor cómo esculpir un objeto 3D o escribir una novela (Ambas formas de expresión artística) es una bestia completamente diferente. Ese es el punto de vista del que vienes.

El software basado en la web requiere un tipo de pensamiento completamente diferente que el software de escritorio. Ambos son completamente diferentes cuando se aplican a juegos versus un entorno de trabajo. Sospecho que trabajar en un sistema operativo o sistemas integrados también requiere pensar de una manera diferente (pero no tengo experiencia con ellos). Y no tengo dudas de que hay otros dominios que también requieren una forma diferente de pensar.

Resumen y ejemplos:

"Arte" incluye esculturas, novelas, cómics y pinturas. Las superposiciones de habilidades incluyen:

Forma del cuerpo y teoría del color: esculturas, cómics y pinturas.
Comunicación textual: novelas y cómics

... Y así. Pero como se mencionó anteriormente, es poco probable que a un artista de cómic le vaya bien en su primera novela. Necesitan pensar de manera diferente.

Del mismo modo, hay una superposición en diferentes campos de la programación / ingeniería de software, pero la mayoría de ellos son demasiado distintos para poder entrar. Por ejemplo:

Algoritmos: SO / sistemas integrados, juegos y otros lugares que a menudo necesita optimizar para velocidad o memoria. Raramente un gran problema en el desarrollo web
Diseño: en todas partes en el desarrollo web, pero no muy importante en sistemas integrados sin una interfaz de usuario.
Software cliente / servidor: la mentalidad de "no confíes en el cliente", que no necesariamente existe en algunos dominios (juegos de un solo jugador y otro software de escritorio independiente, que admito que es más raro en estos días).

— Izkata
fuente

Siempre he argumentado que la programación y el diseño de software es tanto un arte como ciencia o ingeniería. Supongo que este es otro ejemplo de cómo son similares.

— Izkata

Ah, y antes de que alguien me muerda por "Algoritmos", estoy hablando de los CS-y de alto nivel. Los montones de Fibonacci y Timsort son dos que vienen a la mente. (Casi nunca trabajo en ese nivel de complejidad algorítmica, así que sé poco sobre ese tema)

— Izkata

0

¿Todos los trabajadores de la construcción de carreteras pueden usar cada pieza de equipo y maquinaria en el lugar de trabajo? La respuesta es no. Hay piezas de maquinaria que conocen y que probablemente estén familiarizadas con las demás. Lo mismo debería ser cierto para los ingenieros de software, hay una cantidad de idiomas y marcos que conoce porque trabaja con ellos todos los días, pero no se debe esperar que conozca las operaciones exactas de los demás sin un poco de capacitación. Es como tomar el martillo neumático y asignarle la tarea de conducir la mezcladora de cemento.

Los lenguajes y marcos de programación son solo herramientas en un cinturón de herramientas de ingenieros de software. Hay algunas herramientas que conocerá mejor que otras debido a la experiencia. En definitiva, la mejor herramienta es comprender los conceptos y principios básicos de la informática. Elegir idiomas y marcos es simplemente seleccionar qué destornillador usar en cada tornillo.

— Colin D
fuente

2

Esta es una mala analogía, están hablando de ingeniería, no de trabajadores de la construcción, a pesar de que mezclan las metáforas en la pregunta. ¡Para ese fin, se espera que todos los ingenieros civiles que construyan caminos puedan construir cualquier tipo de camino! Al igual que cualquier conductor de camión volquete que transporte el asfalto a dicho sitio de construcción debería ser capaz de conducir cualquier tipo de camión volquete.

1

@JarrodRoberson Estoy de acuerdo en que es una analogía pobre, pero no estoy seguro de que su afirmación de ingeniero civil sea mejor. Claro, cualquier ingeniero civil debería poder leer los planos de cualquier camino. Pero si está construyendo una pista o un camino de hielo, ¿quiere contratar a alguien que haya pasado años construyendo autopistas, o quiere a alguien que tenga experiencia específica con pistas o caminos de hielo?

— Caleb

0

Este tipo de cosas pasan mucho donde trabajo.

Me gusta compararme con la profesión del tío de mi esposa: un mecánico de automóviles.

Se especializa en Mercedes, puede aplicar sus conocimientos a otras marcas de automóviles, y lo hace, algunos de ellos bastante raros, pero eso no significa que pueda reparar de inmediato la X porque usted dice que está haciendo ruido.

Programo en algunos idiomas, pero eso no significa que sepa por qué Safari en su MacBook vuelve a cargar páginas cada vez que cambia de pestaña (la extraña llamada de hoy). Trataré de averiguar por qué, pero no voy a saber de la cabeza porque el campo de la computación es ENORME .

En ambos casos, después de pasar un tiempo buscando en nuestros respectivos campos, probablemente podríamos encontrar la respuesta, pero no en los diez segundos que la gente piensa porque "pero trabajas con autos" o "pero trabajas con computadoras".

¿La gente dice tales cosas a su médico local (como "Me duele la cabeza, ¿qué enfermedad tengo?"). Apuesto a que lo hacen porque la mayoría de las personas realmente no entienden que hay más en una profesión que sus expectativas inmediatas. de dicha profesión.

— Reuben Mallaby
fuente