Login Barrapunto
El software es difícil
Recientemente se ha publicado un libro titulado Dreaming in code al que se le está dando mucha publicidad en los medios anglosajones. Mi opinión personalísima sin haberlo abierto es que no aporta nada que no apareciese ya en The mythical man/month . Sin embargo una entrevista a Scott Rosenberg, autor del libro, ha desatado el debate en Slashdot. Los sospechosos habituales -requisitos cambiantes o inexistentes, programadores que añaden complejidad innecesaria, defectos en sistemas operativos y lenguajes de programación, metodologías ágiles o en cascada, malas condiciones laborales y jefes sin formación tecnológica- han sido mencionados. Hace unos meses también nos preguntábamos aquí por qué es tan difícil desarrollar software. ¿Y tú, piensas que el software es difícil?
Este hilo ha sido archivado.
No pueden publicarse nuevos comentarios.
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
¿Es difícil, o lo hacemos difícil?
(Puntos:5, Inspirado)( http://bardok.net/ )
En nuestra profesión estamos en lo de siempre: si tú encargas una mesa con estanterías (sin ánimo de ofender a la muy noble profesión de la ebanistería), y te hacen un presupuesto y te dice que está para el día X, tú no puedes coger y, una vez empezado a hacer el mueble, decir que resulta que te has dado cuenta que quieres los cajones más pequeños, un color diferente, rebordes metalizados, y que encima, además de hacer la función de una mesa con estanterías te sirva para guardar botellas de vino, todo por el mismo precio y para el mismo día.
Pero como en la informática sí dejamos que hagan estas cosas, o dejamos las especificaciones de requisitos demasiado abiertas como para que el cliente piense que puede hacer este tipo de cosas, pues como para ser sencillo todo el tema de hacer software...
El libro lo he encargado en Amazon nada más ver la noticia en Slashdot y leer la entrevista... a ver si me da ideas de cómo hacer las cosas más sencillas
Lo es pero no tanto
(Puntos:3, Interesante)Hay que tomar conciencia de que para desarrollar algo tan complejo se necesita una metodología, aunque haya varias alternativas, siempre va a ser mejor que ponerse a programar a lo loco. Y esto lo deben entender sobre todo los que deciden, pero los programadores/diseñadores son los que tienen que hacerles ver esta necesidad. Además en el caso de España, primero se tiene que tomar la informática en serio, como una industria, si no nos estaremos perdiendo un sector que es muy importante y más que va a serlo en el futuro.
Re:Lo es pero no tanto
(Puntos:5, Inspirado)Ése no es el problema. En realidad, la pregunta está (un poco) mal formulada: ¿es tan difícil hacer buen software? Vale: es difícil hacer puentes, pero el mundo está lleno de puentes ¡que no se caen! De hecho, cuando se cae un puente es una noticia de primera plana porque prácticamente nunca se cae uno. ¿Y proyectos de software? Prácticamente todos (el 100%) de los proyectos de software se van de límites: o son más caros de lo que deben o están plagados de defectos que no tendrían por qué estar allí.
Y la base del problema está justamente en tu frase: el desarrollo de software *NO* es una ingeniería y tomarla como tal es la madre de todos los problemas.
El desarrollo de software, a fecha de hoy, es una artesanía y requiere lo que todas las artesanías: buenos artesanos y tiempo para llevar a cabo un buen trabajo. Como vemos todos los días, los responsables de proyectos creen que, como es una ingeniería, las piezas (los programadores) son intercambiables (dentro, más o menos, de su especialidad o a veces ni eso). Y no; igual que no puedes cambiar a un buen artesano fabricante de botijos por uno mediocre (ni por dos o tres, normalmente), especialmente cuando de lo que se trata es de hacer un botijo difícil, los programadores -artesanos de cuello blanco- tampoco son intercambiables: tres juniors no pueden hacer el trabajo de un senior: por eso las "cárnicas" acumulan fracaso tras fracaso en términos objetivos, porque se creen que sí lo pueden hacer. Y, por supuesto, tiempo: toda artesanía requiere un tiempo propio; si necesitas acabar una obra más rápido (véase, por ejemplo, la M30 en Madrid y las elecciones a la vista) puedes doblar turnos y meter más operarios; el software, como es una artesanía, no tolera eso: no puedes, simplemente, partir el plan de trabajo y meter más gente y, curiosamente (o no tan curiosamente, si tenemos en cuenta que se trata de una artesanía) normalmente la forma de minimizar riesgos es usar grupos pequeños de desarrolladores firmemente integrados y que confían unos en el trabajo de otros.
"Hay que tomar conciencia de que para desarrollar algo tan complejo se necesita una metodología, aunque haya varias alternativas, siempre va a ser mejor que ponerse a programar a lo loco."
Primero: eso es una obviedad de tal calibre que el mero hecho de que te tomes la molestia de indicarla y, aún más, que creas que lo que acabas de decir es "+1 inspirado" nos da idea del nivel al que está el patio.
Segundo: ¡por supuesto que requiere una metodología! ¿o acaso te crees que un ebanista empieza un armario por donde le da la gana? Hacer armarios y, en general, cualquier artesanía *también* tiene su metodología y, por cierto, pese a lo que dicen por ahí, en muchas artesanía se admiten cambios del calibre de los que realmente (leyendas urbanas a parte) se dan en el mundo del software: ¿o te crees que un sastre -uno bueno, otro buen artesano- no es capaz de cambiar los requerimientos sobre la marcha y alargar una sisa o cambiar los puños o el cuello de una camisa por otros de diferente tipo?
Mientras no se entienda que el desarrollo de software es una artesanía (industrializada y compleja, con metodologías analizables con criterios ingenieriles, eso sí, pero artesanía al fin y al cabo) se seguirán dando los problemas que vemos todos los días (y ojo con menospreciar lo propio: algunos de los "pufos" más serios del mundo del software se han dado en los USA, no en España).
Re:Lo es pero no tanto
(Puntos:5, Interesante)( http://127.0.0.1/ | Última bitácora: Lunes, 09 Junio de 2008, 16:05h )
No estoy de acuerdo.
Todo el mundo sabe que una metodologia tiene como fin el hecer las cosas de una forma metodica para poder centrar la atencion en los autenticos problemas que requieren un nivel de frikismo extra.
Por eso los tecnicos, los buenos tecnicos:
- usan patrones de diseños para no reinventar la rueda a cada rato
- usan idioms del lenguaje para tener que pensar cada token
- hacen pruebas unitarias para poder refactorizar a gusto
- usan sistemas de control de versiones para tener hitos funcionales sobre los que volver cuando se les pira la pinza demasiado con algoritmos estramboticos
- usan procedimientos de despliegue automatizado para que sea mas facil meter nuevas versiones mas frikis y usar librerias chachis de terceros
- nombran los elementos de una manera homogenea para memorizarlos mejor (ej: clases en UpperCamelCase u funciones en lowerCamelCase)
- documentan el codigo
- hacen diseños elegantes para que la cosa sea mas mantenible y expandible a base de frikadas nuevas
- establecen normas para poder colaborar con mas gente y hacer proyectos aun mas frikis
Todas estos ejemplos de uso de metodologias los puedes ver si te das una vuelta por proyectos de software libre. Y veras a demas que se da el uso de metodologias a dos niveles: uno segun la tecnologia usada (Java, perl, python, Zope,
Puede ser que se suela descuidar más el tema de definir plantillas para realizar analisis antes de la implementación. Esta suele ser tan informal como permite el IRC o el Mail. Pero el uso de metodologias para las pruebas unitarias, despliegue, notacion, documentacion,
El problema no es el que los tecnicos no acepten las metodologias, es que se les trate de imponer patochadas para aparentar ser una empresa que trabaja bien. Documentar por documentar, realizar pasos que no dan valor añadido, que la metodologia solo tengas que hacerla cuando la fecha de entrega esta lejos,
Hay infinitos universos paralelos. Disculpe si en alguno digo alguna sandez.
Pues...
(Puntos:4)Difícil no sé, pero barato, es muy barato, al menos en España. Y lo barato sale caroooo...
Opinemos
(Puntos:3)( http://www.obiterdicta.net/ | Última bitácora: Viernes, 15 Agosto de 2008, 11:33h )
Eso es lo que se llama una opinión bien formada.
Antes de que sea tarde, ¡Liberad a Wiindows! [webcindario.com]
Re:Opinemos
(Puntos:4)Yo me lo guiso yo me lo como
(Puntos:5, Interesante)( http://barrapunto.com/ )
Porque se cuelga el software o no hace lo que debe y en cambio los edificios no se caen ? (no confundamos las anécdotas con las excepciones)
Porque los ingenieros de software pican el código y los arquitectos no ponen ladrillos ?
Lo que hace falta es una estructura clara, especialización, responsabilidades. Dejar de lado el concepto de "los programas fallan, por eso los arreglamos" y pasar al concepto del trabajo bien hecho.
Si hubiera ingenieros de software diseñando las aplicaciones, solo diseñando las aplicaciones, y se les hiciera responsable de los errores de diseño entonces el software funcionaria mejor. Si hubiera programadores programando el software, solo programando el software, y siendo responsables de los errores de programación entonces el software funcionaria mejor.
Si dejáramos de contar con que los usuarios finales nos harán las pruebas del programa y las hiciéramos de forma interna y correcta, entonces el software seria mejor.
Pero claro, es mas barato hacer software que no vale una mierda, usando "ingenieros para todo" y vender a los clientes supuestos parches, que no son mas que chapuzas, en forma de servicios.
Complejidad
(Puntos:3, Interesante)( http://www.thealphasite.org/ )
Tendemos a establecer comparaciones de la ingeniería informática con arquitectura, como si construir un programa fuera lo mismo que construir un edificio, quizá porque los pasos son similares en nombre (también se planifica, también se realiza una estrategia, se modela lo que sea desea construir, se construye y se comprueba que todo está bien) sin embargo no tienen nada que ver, hay una diferencia fundamental, el numero de variables implicadas.
La principal dificultad en toda programación es que lo que tu programas no tiene nada que ver con lo que realmente se ejecuta y no tiene absolutamente nada que ver con lo que el usuario ve. Hay que ser realistas,, hay demasiadas variables a tener en cuenta como para esperar que un programa no tenga fallos.
Un ejemplo muy sencillo, la concurrencia que es, en principio, no determinista. Esto significa que los programadores tenemos que imaginar como irán entrando las tareas y prever todas las posibles combinaciones en nuestra cabeza porque ni siquiera existe un caso en el que podamos verlo in situ. !! Quisiera ver a los arquitectos diseñando edificios si la estructura de la materia fuera no determinista¡¡ "si, esta viga es de hierro recubierta de hormigon los días pares pero si se construye en un día impar entonces es de hormigon recubiera de hierro"
Al ingeniero de software además se le exige toda una serie de requisitos (a veces miles) que debe cumplir expresados en lenguaje llano del usuario y tienes que cumplir todas y cada una de ellas. En arquitectura construyes una vez y la gente entra a ocupar, por definición el numero de variables a tener en cuentas es significativamente menor y además, enumerable, revisable y comprobable hasta la última de ellas. En programación no tienes ni por donde empezar: "mi programa ha cargado en una dirección de memoria rara", "me he quedado sin memoria física Y sin swap", "el planificador ha decidido que ya no ejecuto más y no me ha dado tiempo a volverme a meter la polla en los pantalones antes de echarme" (si, en esta obra hay más de un arquitecto trabajando a la vez)
El problema está en la cantidad de variables, la cantidad de cosas que hay que tener en cuenta, pensamos que es lo mismo que la arquitectura pero no lo es, los proyectos seguirán saliendo tarde y seguirán conteniendo errores que habrá que corregir. Para mi la programación se parece más a la física, toda "teoría" esta evolucionando, ajustandose y siempre habrá cosas que no se han tenido en cuenta
No silver bullet
(Puntos:1, Inspirado)Parece mentira que nadie haya citado todavía el clásico y obligatorio texto que oh vosotros ingenieros del software deberíais tener como una de vuestras lecturas de cabecera (TM) de Frederick P. Brooks, Jr: No Silver Bullet [berkeley.edu], dónde se explican las características inherentes al software que hacen, por definición, que éste sea esencialmente complejo:
[...] I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems.
If this is true, building software will always be hard. There is inherently no silver bullet.
Let us consider the inherent properties of this irreducible essence of modern software systems: complexity, conformity, changeability, and invisibility.[...]
y el texto sigue a partir de ahí desglosando cada una de esas propiedades. Para el que no lo conozca, se trata un texto de 1.986 sobre el desarrollo de software, y para lo que ha llovido desde entonces, sigue siendo plenamente vigente. Ahora regaládselo a vuestros jefes, existe una remota posibilidad de que entiendan. Y si no entienden y vosotros aguantais el tirón y seguís haciendo ese software tan maravilloso que caracteriza a la consultoría española... pues allá vosotros, pero no os quejéis de lo mal que va el mundo Facundo (por cierto, es probable que un jefe que entienda te valore más, te haga evolucionar más y hará que disfrutes de mucha más calidad de vida en tu trabajo que el que aguantas ahora mismo Y, antes de que salte nadie, estoy hablando con aquellos que desempeñan profesionalmente su trabajo como método de evolución profesional, no con esas "personas" que se acuestan con otras como método de evolución profesional :-P).
Aagur chavales!Comentario que será impopular, pero......
(Puntos:1, Inspirado)Sin embargo, practicamente cualquier diseño electrónico implica muuuucho tiempo y muchos quebraderos de cabeza. El diseño hardware es trabajoso, la infraestructura base es muy cara y muchas veces no se dispone de las herramientas necesarias, la depuración es dificil y limitada y sobre todo, al hardware se le exigen unos niveles de calidad muy superiores al del software. ¿Cuantas veces en un par de años se nos cuelga nuestro S.O. y cuantas veces al año tenemos un fallo en nuestra placa madre? ¿o cuantas veces falla el hardware de nuestro ascensor, o de nuestro microondas, o de nuestro equipo de musica, o de nuestro telefono movil?. ¿Realmente nos paramos a pensar alguna vez la complejidad de diseño electronico de estos equipos?.
Si cogemos cualquier equipo electronico que utilice software, el software (de alto nive, que es al que se refiere este articulo) puede ser de las partes mas sencillas de desarrollar de todo este equipo.
Quisiera ver al arquitecto ...
(Puntos:2)( Última bitácora: Domingo, 11 Junio de 2006, 20:58h )
Eso es lo que nos encontramos todos los dias nosotros los que programamos. Si es que es para ponernos en un pedestal o en un manicomio, no acabo de decidir dónde.
Depende mucho del jefe de proyecto
(Puntos:1, FueraDeTema)( http://tecnochapuzas.zapto.org/ | Última bitácora: Martes, 12 Agosto de 2008, 22:51h )
--- Si te gusta la electrónica y la informática, nos vemos en #Tecnochapuzas del IRC-hispano
La construccion no es un referente
(Puntos:1)( Última bitácora: Jueves, 08 Marzo de 2007, 10:31h )
En la construcción constantemente hay fallos, y sinó acerquense a un edificio recién entregado a los primeros propietarios, suelos desnivelados, tuberás que se atascan, paredes con humedad, un amigo constructor me comentó que una vez tapiaron las ventanas del patio de luces!!! jejeje, por no hablar de la cantidad de muertos en accidentes laborales que hay cada año.
No sé como será en otros paises, pero no creo que el sector constructor sea un referente a la hora de compararse con el sector informático.
El software es más complejo, sin duda
(Puntos:1)( http://ignaciocalvo.com/ )
Es un problema de ámbito: la arquitectura puede ser todo lo compleja que queramos, pero por lo menos sabemos que se limita a la construcción de edificios. El software tiene un ámbito ilimitado. Un programa de arquitectura puede ser tan complejo como el proceso íntegro de construcción de un edificio: basta con que modelice dicho proceso. Podemos hacer un programa tan complejo como cualquier proceso de cualquier ingeniería. Al englobar cualquier posible proceso intelectual, el software no es que sea tan complejo como cualquier disciplina ingenieril que podamos concebir; es que es más complejo que la suma de todas ellas.
Por eso es tan complejo crear metodologías que valgan para todo: en el fondo estamos lidiando con la antigua tarea de modelizar la mente humana (al menos la parte racional). Por eso el software es tan complejo.
Esto no quita, claro, para que, una vez limitados a cierto ámbito del desarrollo software (por ejemplo, ofimática o diseño CAD), sí que sea posible crear metodologías concretas que hagan la tarea mucho más sencilla. Pero no se puede defender la postura de que existen disciplinas ingenieriles más complejas que el desarrollo software.
Saludos! Mandel
Despues de haber leido todo los comentarios.
(Puntos:1)( http://www.programacionjuegos.net/ | Última bitácora: Miércoles, 14 Febrero de 2007, 14:50h )
Es mejor saber una metodologia o saber un lenguaje de programación ? (lo digo por la gente superior, lo super ingenieros que todo lo saben) lo dejo en el aire.
Deberiamos tener un pressupuesto, para programadores , testers, debugers, y si al gran ingeniero del software que te hace un esquemita con miles de flechas que se pierden por bases de datos absurdas, jeje me estoy passando un poco es broma que conste, como dividir esas partes, si a un mecanico le pide que te cambie el cristal te cambia el cristal de la casa y punto, si a un programador, tecleador de codigo, le pides que te canvie un cristal , podria perdirte que tamaño tiene, que material, o simplemte dejarte la opción para que parametrices los datos requeridos tu mismo, o automatizaria el processo , o crearia una rutina de programacion, para que el cristal se cambie mañana a las doce que es cuando llega el cristal. No sé si habeis visto un poco como creo que funciona la mente de un mediocre programador.
Y por ultimo cuantas decadas se necessitan para hacer buen software?
Bueno y otra cuantas para que sea rentable?
Yo creo que la rentabilidad en casos como windows ganan al buen software , algo inquietante que da que pensa(iker
Miradlo como una ventaja
(Puntos:1)El diseño del software es complicado, los sistemas de información que modelamos están mal definidos, nos cambian la especificación ...
¿Por qué no lo miramos como una ventaja? ¿Por qué no empezamos a vender que nuestro trabajo es gestionar y adaptarnos al cambio? Para eso tenemos que hacer sistemas flexibles, incrementales, fáciles de mantener y de modificar. No me invento nada. Todo está ya escrito por gente como Scott Ambler [ambysoft.com] o Kent Beck [wikipedia.org].
Todo sería muy fácil si nos dieran la especificación sellada, firmada y grabada en piedra. Pero el mundo no funciona así. El mismo tio que ha hecho la especificación (por muy claro y formal que sea) va a tener que cambiarla mañana cuando el negocio de la competencia introduzca cambios que haya que copiar (ejem, mejorar). Hagamos de eso nuestro negocio y vendámosle un contrato de mantenimiento tan caro (o más) que el de desarrollo.
Re:dfgfhgf
(Puntos:1, Divertido)( http://txixco-mex.blogspot.com/ )