domingo, diciembre 31, 2006

Betanzos en la red

domingo, diciembre 31, 2006 por Martín

Cuando comencé este blog como continuación de mi viejo blog uno de mis propósitos era poner muchas más entradas sobre mi ciudad natal, Betanzos. Pero la verdad es que con el cambio de ciudad, ahora estoy mucho más alejado de mi ciudad (sí, desde el 1467) de lo que me gustaría.

Por suerte hay una serie de recursos en Internet que ya hacen el trabajo por mi, y me mantienen actualizado. el pasatiempo es probablemente uno de los más actualizados, con posts bastante frecuentes. A partir de ahí, hay otra serie de blogs con diferentes contenidos. Podría recopilarlos aquí, pero ya lo han hecho por mi.

El caso es que no deja de ser curioso como el movimiento de los blogs, reciente donde los haya, ha hecho aumentar exponencialmente el número de páginas relacionadas con Betanzos, cuando hace varios años se contaban con los dedos de una mano. Aún más curioso es ver como muchos de los blogs tienen una clara tonalidad política, para un lado, para el otro, o para el medio. No es algo que me moleste especialmente, aunque sí que confieso que no leo ese tipo de posts.

En fin, de cualquier modo aprovecho para desearos a todos los que os pasáis por aquí un Feliz Año 2007. Por mi parte toca ir a cenar ya, tomarse las uvas, y un año más salir por una de las mejores ciudades (sí, desde el 1467) españolas para celebrar el fin de año.

¡Feliz 2007!

miércoles, diciembre 27, 2006

Cuatro años bloggeando

miércoles, diciembre 27, 2006 por Martín

Pues parece que sí, llevo ya al menos cuatro años bloggeando. Leyendo el siempre interesante weblog de Aitor, me enteré de que él lleva cuatro años bloggeando. Tras eso me entró un poco la melancolía recordando todo lo hecho en los últimos años, los congresos, las charlas representando a javahispano por España, los proyectos iniciados en jh, los que salieron bien, los que salieron mal, y todas estas cosas.

El caso es que al final me pregunté: Y yo, ¿cuánto tiempo he estado bloggeando? Y cual fue mi sorpresa al descubrir que ¡mi cuarto aniversario fue ayer! La verdad es que no me esperaba que fuese hace tanto tiempo, pero se ve que el tiempo pasa muy rápido. Mis comienzos fueron curiosamente (no creo) los mismos que Aitor, pidiendo de prestado en freeroller.net. Mi final, sigue siendo de prestado pero ahora en blogger. Mi camino es mucho menos traceable que el de Aitor porque siempre ha sido muy irregular, de hecho he alternado blogging en inglés y español, y en diferentes servidores. Atrás queda un ya irecuperable blog en blog-city (¡no me acordaba de eso!), otro en javahispano, otro más, éste en inglés, en jroller, otro que está ahora mismo en estado de coma en blogspot (el hermano de éste, pero en inglés), y por último éste que estáis leyendo.

Que emocionante leer los posts de hace cuatro años. En cierto modo es como cuando hace años leías cartas que habías recibido o que no llegaste a enviar. En fin, ¡que recuerdos! :)

domingo, diciembre 24, 2006

Vacaciones y Irish seals

domingo, diciembre 24, 2006 por Martín

El pasado sábado comenzaron mis vacaciones de invierno, así que me esperan unos días muy, pero que muy, relajados. Ayer, me acerqué al puerto de Dún Laoghaire para intentar comprar algo de marisco fresco (y barato) en el puerto. El caso es que cuando llegué, ya no había nada de lo que buscaba (aunque sí que había buen pescado fresco) así que me acerqué a una pescadería de la zona. Por cierto, aquí el marisco no es demasiado caro, al menos en comparación con otras cosas. Un kilo de cigalas (pequeñas) y un kilo de mejillones me han salido por 16 euros, y las cigalas se movían por lo que no me parece una barbaridad.

Bueno, dejando a un lado el marisco, lo que realmente me sorprendió es que cuando estaba en el puerto me acerqué a la orilla porque oía unos ruidos y me encontré frente a frente con este personaje:



Fue muy simpático porque yo había oido ruidos, pero me esperaba algún pescado chapoteando, no una genuina Irish seal. Las focas irlandesas son una especie autóctona de aquí pero aún no había tenido la oportunidad de ver una, y la verdad es que me pilló desprevenido. Esto no hace más que reafirmarme en mi opinión de que no pienso ir a bañarme el día 25 de Diciembre después de ir a misa, como algún amigo de la oficina me ha propuesto. No por las focas, sino por la temperatura del agua.

El caso es que he subido el video a YouTube para hacer famosa mi amiga la foca. :-)

martes, diciembre 19, 2006

Juegos en la empresa

martes, diciembre 19, 2006 por Martín

Sin lugar a dudas, una de las formas más originales de probar un producto, y que he tenido la oportunidad de experimentar este año, es la de jugar con él. Sí, jugar, habéis leido bien. Intentaré explicar el concepto en los siguientes párrafos.

Cuando un producto está llegando a su fecha de lanzamiento empieza el periodo estresante de pruebas exhaustivas. Normalmente, el producto se cerrará en cuando a código fuente y a partir de ahí entrará en proceso de integración y pruebas por parte del equipo de tests. Una vez que termine este período, podremos lanzar nuestra tan esperada versión. Obviamente, nos interesa que cuando el producto llegue a manos del cliente, éste se encuentre impecable y totalmente libre del más mínimo error, problema de rendimiento, agujero de memoria, o cualquier otro efecto indeseable.

Si nuestro proceso de pruebas e integración es extraordinario, todo irá como la seda. Pero la realidad es que las cosas no suelen ser así. Aunque nuestro proceso de pruebas sea perfecto desde el punto de vista formal, la realidad es que siempre existe un factor importantísimo que no podemos controlar: el factor humano.

El factor humano es importantísimo a la hora de probar un producto, porque por muchos tests unitarios, de integración, de rendimiento o funcionales que tengamos, ¿saben realmente nuestros desarrolladores lo que están probando? Es más, ¿saben nuestros desarrolladores como funciona el producto?, ¿saben como es el interfaz de usuario?, ¿saben como se comunican los componentes?, ¿se han puesto alguna vez en la piel del usuario final? Probablemente la respuesta a todas estas preguntas sea afirmativa si estamos hablando de un producto pequeño, pero sin embargo, cuando hablamos de un equipo de cientos de desarrolladores, de productos con decenas de módulos diferentes, y de grupos de desarrollo diversos (incluso deslocalizados), entonces la respuesta será un conjunto de noes.

Una de las formas de afrontar este problema es jugar. Sí, jugar, como leéis. Dependiendo de la aplicación se podrán crear diferentes tipos de juegos. No todas las aplicaciones son "jugables". Unas lo son más que otras. Por ejemplo, si estamos creando un juego para un periódico nos será sencillo el crear un juego virtual dentro de la empresa; si estamos trabajando en un producto para invertir en el mercado bursatil, podremos crear un juego de inversión en bolsa; si estamos creando una tienda online podemos crear un juego en el que ganaría el que más compras realize, o el que más dinero gaste, o cosas así; si estamos creando una aplicación de gestión de un servicio médico, podemos premiar a los que más pacientes traten o examinen completamente, a los que más informes creen, etc. etc. En fin, hay muchísimos ejemplos, unos más sencillos, otros más complejos.

Una vez que tenemos definido el juego es importante crear el entorno de ejecución del mismo. Este entorno debería simular de algún modo el entorno de producción real. Como la carga de usuarios será menor, se debería escalar este sistema para alcanzar algún tipo de relación con la carga de usuarios esperada. En general el sistema será mucho más pequeño que el de producción, pero debería ser lo suficientemente significativo como para generar problemas que podrían aparecer en producción.

Una vez que tengamos definido todo esto, llega el momento de jugar. Pero bueno, a estas alturas estaréis pensando, pero éste realmente se piensa que la gente va a ponerse a jugar con todas las cosas que tienen que hacer. Tenéis toda la razón del mundo. Todo esto no es suficiente si no se toman algunas medidas muy importantes:


  • Premios en metálico.

  • El juego debe ser obligatorio.



Como apunto en la lista, el juego debe tener obligatoriamente premios, y si es posible debería haber premios en metálico para todo el mundo. Por ejemplo, en el ejemplo de la tienda, se podría ofrecer a los empleados el 5% del importe de todo lo que compren hasta un límite de 1000€; o en el juego de la bolsa, pues el 5% de las ganancias que consigan + 5€ por operación realizada hasta 1000€.

Tener premios sin duda estimulará a la gente a participar. Una opción interesante es contactar con el cliente para conseguir ese dinero en metálico. Este tipo de juegos suele atraer la atracción del cliente final, ya que muestra que existe una intención real de hacer una prueba extensiva del producto. De hecho, si el cliente final es una organización, probablemente les interese a ellos mismos realizar un juego interno posterior dentro de la propia compañía.

También es muy importante que el juego sea obligatorio. Este tipo de prácticas ofrecen una enorme oportunidad para simular el comportamiento real de la aplicación, con personas reales y en un entorno similar al entorno de producción. Por eso es tan importante que participe la mayor cantidad de personas como sea posible. Adicionalmente, este tipo de juegos sirve para que los desarrolladores se familiaricen con la aplicación, para que entiendan como funciona, para que se pongan en la piel del usuario final y se enfrenten al interfaz de usuario, para que se den cuenta ellos mismos de los diferentes problemas. En fin, son demasiado valiosas como para que no se realicen. Por ello debe obligarse a los desarrolladores (y a testers, y soporte técnico, y managers, y a todo el mundo) a participar en el juego.

La participación no tiene porque ser constante, ya que también queremos que las personas trabajen. Se pueden organizar periodos de participación durante el día, o quizás ofrecer herramientas que automatizen el juego para que no haya que estar todo el día mirando para la pantalla para ganar.

Este año, he tenido la oportunidad de participar en uno de este tipo de juegos y la verdad es que la experiencia fue increiblemente positiva, y todo el mundo coincidió en lo mismo. Son experiencias que no sólo te ayudan a aprender como funciona el producto, sino que ofrecen un enorme abanico de posibilidades a la hora de probar realmente las aplicaciones.

Me pregunto si alguien tiene expriencias que compartir sobre este tema que personalmente me parece muy interesante. Ahí queda la oferta.

lunes, diciembre 18, 2006

Irlanda: Otro mundo en cuanto a Internet

lunes, diciembre 18, 2006 por Martín

Llevaba tiempo queriendo escribir algo sobre esto, y es que la verdad es algo que me ha sorprendido mucho desde que estoy aquí en Irlanda. La verdad es que sí, cuando vienes aquí piensas que lo normal será que estén más avanzados en cuanto a tecnologías de la información, ya que aquí se encuentran prácticamente toda las empresas importantes no sólo de Europa sino también del mundo, pero desde luego no te imaginas la adicción que tiene esta gente por esto de Internet.

Una de las cosas que más me ha sorprendido es que prácticamente todo el mundo tiene su página web. Que vas al gimnasio, tienen página web. Que vas a la iglesia, tiene página web. Que tienes que comprar pescado, el pescadero tiene página web (obviamente no llegan al nivel de la compra online, pero al menos sabes donde está). Tu pub preferido, todos tienen página web. El de las cortinas, página web. Te pasas por el centro comercial y recoges el periódico gratuito de la zona, y todo los anuncios que salen vienen con su página web. Y es que aquí tienen muy claro que si tienes un negocio, tienes que estar en Internet.

Y es que no en vano Irlanda es el pais de Europa que que más se dinero se gasta en la compra online, llegando a gastar el doble que cualquier europeo. Nada más y nada menos que un 24% de los usuarios de la web en Irlanda afirman comprar en Internet, y un 47% planean hacer la compra estas navidades. Y es que como se puede leer en el informe State of the net este es un negocio en el que una compañía de procesado de transacciones online puede llegar a mover 15 millones de euros diarios.

Claro, a eso ayuda que prácticamente el 50% de la población esté conectado a la red y que de ese 50% el 78% de los usuarios de internet estén utilizando banda ancha, algo que no sucede en todos los paises.

Una de las cosas más curiosas que también he notado es la adicción que tiene esta gente a eBay. Todo el mundo en mi trabajo compra cosas en eBay. Vale, comprar en eBay no es algo raro, pero, ¡¿qué todo el mundo compre?! Y es que aquí hay auténticos profesionales de la compra online. De hecho no es raro encontrar alguna tienda en la que simplemente dejas tus cosas y ellos te las venden en eBay.

Una de las consecuencias de todo esto es que uno tiene la sensación de que hay oportunidades realmente interesantes. Probablemente Irlanda sea uno de los mejores paises para crear un negocio online realmente productivo. Y es algo que lo notas constantemente, en la calle, en el metro, en la televisión. Tienes esa sensación de que realmente Internet es un canal de marketing y ventas realmente importante.

En fin, que es una cosa a analizar :)

sábado, diciembre 16, 2006

Comet, reinventando términos

sábado, diciembre 16, 2006 por Martín

Uno de los términos técnicos del que más se ha leído durante este año es el de Comet. Este término se ha asociado con el mundo de AJAX aunque la realidad es que es un concepto que viene desde mucho más atrás.

El streaming HTTP es la técnica más básica de cualquier compañía que se dedique al mundo de la bolsa, comercio de divisas, o en resúmen cualquier mundo en el que se necesita empujar datos al cliente a velocidades de vértigo. Por ejemplo en el mundo del intercambio de divisas todos los interfaces se basan en este concepto ya que la volatilidad del mercado es brutal y cuando estas operando con monedas con mucha volatilidad, unos pocos segundos pueden significar cientos de miles de dólares.

El streaming HTTP se puede realizar tanto desde un cliente web como desde una aplicación de escritorio tradicional. No es algo que esté ligado para nada con AJAX. Por ejemplo, puedes tener tu aplicación de escritorio interactuando con un banco a través de HTTP y mantener dicha conexión abierta para que el servidor te esté continuamente haciendo streaming de datos. Como he dicho, esto es algo que se ha estado haciendo durante años. En estos casos, el usar una técnica como esta y mantener la conexión habierta es algo básico ya que es físicamente imposible el soportar una comunicación mediante polling. Si alguno se está preguntando porque utilizar HTTP, simplemente debe pensar que estamos hablando de bancos, y los firewalls son muy importantes en los bancos :-), especialmente cuando tu objetivo es el retail, es decir, el público de a pie.

Existen muchos recursos actualmente sobre Comet, AJAX, NIO, etc. y este año ha sido uno de los mejores para este terreno. Servidores web como Jetty o Apache Tomcat 6 soportan ya el mantener conexiones persistentes con el cliente a través de Java NIO, pero el caso es que la historia no se ha acado todavía ahí. El problema más importante ahora mismo es que aunque escales en la capa Servlet, todavía tienes que escalar en el Apache que los bancos te suelen ofrecer como entrada, ya que no sirve de nada liberar threads en tu contenedor web si están bloquedas en el servidor HTTP. Existen opciones como Grizzly, que es un servidor HTTP que utiliza NIO por debajo, pero la realidad es que es poco probable que estas organizaciones te permitan instalar este tipo de software en su puerta de entrada al mundo exterior.

Ante esta situación sólo queda esperar. Probablemente el próximo año se harán muchos avances en este sentido, así que promete ser un año emocionante.

Pruebas proactivas, tests de integración y equipos de tests

sábado, diciembre 16, 2006 por Martín

Hay un dicho que suele decir que un poco de prevención vale más que un mucho de curación. Personalmente, este dicho lo aplicaría al mundo de las pruebas de software para crear el concepto de pruebas proactivas.

¿Qué es una prueba proactiva? : Una prueba proactiva es aquella cualquier prueba que no tendríamos obligatoriamente que realizar pero que nos permite adelantarnos a los acontecimientos. La principal ventaja de las pruebas proactivas es que nos permiten crear software mucho más sólido previniendo problemas no esperados desde un punto de vista unitario, integracional o funcional.

Ejemplos de pruebas no proactivas serían aquellas que es obligatorio realizar para mantener un software saludable, como los tests unitarios, tests de integración o tests funcionales.

Ejemplos de pruebas proactivas pueden ser los tests de rendimiento, tests de carga y tests de integración.

Ahora bien, si miráis la lista veréis que los tests de integración están tanto en la lista de pruebas proactivas como en la lista de pruebas obligatorias. ¿Por qué? El problema es que los tests de integración yacen en el limbo de los tests.

En una empresa normalmente tenemos diferentes equipos de desarrollo que trabajan con diferentes componentes. Los desarrolladores de estos equipos tienen la responsabilidad de ofrecer componentes lo suficientemente probados a través de tests unitarios. Por otra parte, hay muchas empresas que tienen un equipo completo de testers que se encargarán de realizar todas las pruebas funcionales de cara al usuario final.

El punto más peliagudo es el de los tests de integración. Los tests de integración se encargan de comprobar que los diferentes componentes de nuestro sistema funcionan como es debido, y que interactuan como se espera dentro de sistemas que imitan al entorno de producción que nos vamos a encontrar. Nótese que la palabra integrar aquí adquiere un significado algo ambiguo y se refiere tanto a integrar dos piezas de software que se deben comunicar entre sí, como a integrar esas piezas de software en un entorno de ejecución determinado.

¿Quién hace y cómo se hacen estas pruebas de integración? Sin lugar a dudas, lo ideal es mantener un equipo de desarrollo de tests de integración que se encargue de desplegar los componentes en un sistema similar al de producción y de probar la integración de estos componentes. Aquí es donde entra la proactividad. Estos equipos de producción deben realizar el test del producto olvidándose del usuario final. Esto permite eliminar la dependencia de los casos de uso y alcanzar una cobertura mucho mayor en nuestro software, ya que incluso aunque estuviésemos cubriendo el 100% de los casos de uso definidos en la arquitectura, la realidad es que probablemente los casos de uso no estan cubriendo el 100% de las acciones que nuestros usuarios realizarán.

El problema de mantener los tests de integración orientados al usuario final es que uno no puede realmente estar seguro de que su software es sólido y fiable. Es muy común por ejemplo en los entornos de tests el realizar las pruebas de integración utilizando robots web o robots de GUI, que se encargan de simular el comportamiento del usuario final. ¿Es esto una prueba de integración real entre componentes? No. Esto son pruebas funcionales, y nunca se deberían tratar como pruebas de integración. El problema es que se tratan como tales debido a falta de presupuesto para contratar equipos de test de integración, a falta de conocimiento por parte de los equipos de testing funcional o a falta de tiempo por parte de los desarrolladores para asumir semejante carga.

En resúmen, ponga un equipo de ejecución y creación de tests de integración en su vida y será mucho más feliz :-)

martes, diciembre 05, 2006

¿ Debería despedir a su arquitecto ?

martes, diciembre 05, 2006 por Martín

Realmente polémico el post de David Linthicum en Infojobs. Debe ser una persona bastante influyente (ignorante de mi, no lo conocía), ya que rápidamente otra serie de gurus se han lanzado a responder vorazmente ante el provocativo post en Infoworld.

A pesar de que estoy de acuerdo con él en algunos puntos, por ejemplo el 1, el 5 y el 6 (no en los despidos), espero que no despidiesen a alguien por no confiar demasiado en SOA ;)

Todo esto via nuevamente InfoQ.

Ron Jeffries sobre metodologías ágiles

martes, diciembre 05, 2006 por Martín

En InfoQ han publicado una entrevista a Ron Jeffries que resulta realmente interesante, ya que no se limita a alabar las metodologías ágiles, sino que adopta un enfoque mucho más realista, mostrando como estas metodologías se comparan con las metodologías más conservadores, y explicando cómo si obviamos el lanzar versiones frecuentes y el probar nuestras funcionalidades el resultado puede ser mucho peor que el que se obtendría mediante un método más tradicional.

Es una entrevista no demasiado larga que se hace bastante amena gracias a las explicaciones que Ron Jeffries va dibujando en su pizarra.

viernes, diciembre 01, 2006

Interfaces de usuario: ¿Construcción manual o automática?

viernes, diciembre 01, 2006 por Martín

En varios sitios web se ha reabierto el debate sobre si es más adecuada la construcción de interfaces de usuario a través de herramientas de generación de código, o si por el contrario es mejor elegir una aproximación más artesana y construir todo el código manualmente.

La verdad es que este es un tema recurrente sobre el que creo que cualquiera pude opinar, ya que asumo que todos los que estamos en este mundillo del software hemos desarrollado algún interfaz de usuario en algún momento de nuestras carreras, ya sea hace años cuando los Visual Basic era una revolución a la hora de crear aplicaciones, ya sea más recientemente en Java con herramientas como Matisse, o ya sea en el mundo web con los diseñadores visuales para frameworks Java Server Faces. Asimismo, probablemente todos hemos en algún momento determinado creado, o intentado crear, esas mismas interfaces de un modo manual, ya sea porque nos apetecía, porque no teníamos otra cosa a mano, o por cualquier otra razón.

Ante una situación como esta, donde cada cual tiene su propia opinión en base a su experiencia, creo que es un poco inútil el caer en discusiones sobre ésta u ésta otra tecnología es mejor, así que intentaré describir lo que en mi opinión son los tres factores más importantes a tener en cuenta, en orden de importancia, a la hora de elegir uno y otro camino:

  1. Experiencia de la gente que disponemos: Lo más importante que se debe tener en cuenta es el tipo de gente con la que contamos en el equipo de UI. Y ante este punto lo más importante es ser realistas y recordar que no debemos elegir en base a nuestras preferencias si no en base a su experiencia y habilidad.

    Si en el equipo de UI cuento sólo con personas con poca experiencia, que no han hecho interfaces visuales previamente, o que vienen de otros lenguajes y no conocen Java, o .NET, o lo que sea, entonces en este caso no tendría demasiado sentido forzarles a programar todo manualmente, ya que les resultará muy complicado. Incluso aunque a nosotros nos parezca una tarea muy fácil, la realidad es diferente: para ellos no lo es.

    Por otra parte, obligar a un grupo de expertos programadores a utilizar un diseñador gráfico puede ser contraproducente, ya que estas personas pueden no sentirse cómodas con estas herramientas, pueden tener ya una serie de procesos que los hagan más productivos y el añadir una herramienta nueva puede significar reemplazar todos esos procesos por algo totalmente nuevo, y finalmente esto puede llegar a causar frustración y desánimo en el equipo.
  2. Complejidad del interfaz de usuario: El siguiente punto a tratar sería la complejidad del interfaz que estamos planeando. Los diseñadores visuales suelen soportar un conjunto limitado de componentes, y en cuanto añades componentes que no esperan el resultado puede ser diferente al que no esperamos. Si nuestro interfaz va a utilizar componentes personalizados, entonces debemos plantearnos seriamente la posibilidad de utilizar una aproximación híbrida o simplemente olvidarnos de utilizar ninguna herramienta.

    Mediante una aproximación híbrida, diseñariamos la mayor parte de componentes con herramientas visuales y posteriormente añadiriamos los componentes propios. El punto crítico aquí es que el proceso de añadir componentes propios debe ser lo menos intrusivo que sea posible, ya que de otro modo las probabilidades de que la herramienta gráfica sea incapaz de volver a recear nuestro interfaz son muy altas.

    Si el número de componentes personalizados es alto; o si estos componentes personalizados se encuentran muy arriba en la jerarquía de componentes ( no es lo mismo personalizar un frame que un botón ), entonces lo mejor sera olvidar directamente las herramientas visuales.
  3. Valorar entre diseñadores visuales y frameworks: Hoy por hoy los diseñadores visuales son muy potentes. Por ejemplo, en Java, hay diseñadores excelentes tanto para Swing como para SWT. Por otra parte, tenemos que de manera alternativa siempre aparecen una serie de frameworks que ofrecen un enorme valor añadido, como pueda ser JGoodies en Java (o incluso los componentes de futuros jdk que van apareciendo en java.net). La mala noticia es que los diseñadores visuales no suelen soportar estos componentes, lo que significa que si realmente necesitamos alguno de estos componentes, entonces tendremos que abandonar la idea de utilizar el diseñador.

    Si por el contrario, no hay ningún framework que nos ofrezca algo realmente valioso, entonces la opción de usar diseñadores vuelve a adquirir valor.


En esta lista los dos primeros puntos son excluyentes y decisivos. Si no tenemos gente experta, lo mejor es ir a las herramientas, mientras que si nuestro interfaz va a ser muy complejo y personalizado, lo mejor es ir al código manual. En caso de empate en esos dos puntos, el tercero debe decidir.

Me dejo muchos aspectos deliberadamente, porque la verdad es que este sería todo un tema para un libro. Otro aspecto importante podría ser la volativilidad del equipo. Por ejemplo, si hoy tengo un equipo muy bueno, y la gente se me va, mañana quizás un equipo menos experimentado tendrá que mantener el código del primer equipo, y en ese caso el trabajar con un diseñador visual facilita las cosas porque para los segundos les será sencillo ver lo que han hecho los primeros. Pero, por ejemplo, por el contrario, forzar a los programadores a no utilizar un diseñador, es equivalente a forzarlos a aprender como funciona una determinada API, lo que siempre es bueno porque aporta conocimiento sobre la plataforma.

En fin, sea como sea, ante todo lo más importante es ser consistente con la decisión tomada. Si elegimos utilizar una herramienta, debemos utilizarla y cuidarnos de que los interfaces se puedan seguir manteniendo con esa herramienta. Si comenzamos a crear pantallas, y posteriormente añadimos mucho código personalizado a estas pantallas, seguramente no las podramos volver a editar gráficamente. La consecuencia es que parte de nuestro interfaz gráfico se modificará con un editor y la otra parte se modificará manualmente, lo que no deja de ser un desastre.

Y para acabar me mojo. Yo prefiero no utilizar herramienta. Siempre que comienzo algún proyecto, intento empezar con alguna, pero al final acabo escribiendo todo a mano. Que se le va a hacer :)