Ten en cuenta que agilismo no es lo mismo que "venga, empezamos a trabajar y ya se verá qué sale de aquí", también hay planificación si conoces los requerimientos.

La ventaja del agilismo está en que no estás 2 meses o más planificando, haciendo diagramas, etc., luego te pones a codificar y hacer pruebas y hasta que pasa un montón de tiempo el cliente no ve nada y, para cuando ve algo, ya no es posible cambiar las cosas sin un gran coste.

Con agilismo el cliente ve, en poco tiempo, un primer boceto de las cosas y es capaz de decidir si eso era lo que quería o no. Eso da pie a una renegociación del acuerdo por ambas partes, si es menester, para cambios no esperados (por ejemplo, si no le gusta lo que ve se le puede decir "lo cambiamos, pero le costará tanto"). El ciclo de desarrollo es un bucle constante donde el cliente interviene activamente, hay nuevos requisitos (o no) y se generan nuevos costes. No sé, es como si vas a un concesionario a comprar un coche y te dicen "vale X", pero luego de verlo ves el modelo superior con GPS y otra pintura y lo quieres, y el vendedor te dice, "no hay problema, ahora vale Y y hay que pedirlo a fábrica". Si te interesa lo coges y si no te quedas el inicial.

Bueno, eso es una pequeña parte de las ventajas que tiene, pero una muy importante a mi modo de ver.

¿Cómo convencer a tu jefe? Ponle ejemplos de casos resueltos con agilismo, explícale las ventajas y demuestra que sale barato teniendo en cuenta las ventajas que aporta. Muestra los inconvenientes de no usarlo, como equivocarse y que el cliente no esté contento con lo que ha comprado. No sé, cada uno conoce a sus jefes y sabe de qué pie cojean.

Por cierto, off topic total pero es que me siento emocionado y tenía que decirlo en algún sitio. Mi ultimo proyecto personal, hecho con Google App Engine, está funcionando: http//www.collok.com

Con él he aprendido mucho sobre Python (no tanto como quisiera, claro), pero sobre todo de cómo funciona GAE, que me ha sorprendido gratamente (aunque ciertamente, cambiar el chip de SQL a NoSQL me ha costado bastante, después de casi 20 años usando SQL). Y, además, es mi primera web "responsive" y adaptada a móviles. Vamos, todo un compendio de detallitos.

Pero claro, corriendo sobre un hardware adecuado que la deje rendir bien, sino apaga y vámonos.

Yo tengo máquinas para diferentes propósitos con todas las herramientas relacionadas (desarrollo web, desarrollo de escritorio, diseño gráfico...) pero lo más ligeros posibles (menos recursos cargados y menos disco a emplear) y, si me tengo que desplazar por trabajo sabiendo en lo que voy a trabajar, me llevo mi entorno ligero y lo ejecuto en cualquier lado.

Si patentas un algoritmo demasiado complejo, siempre podrá cogerse y, cambiando un par de formas de calcular las cosas o los pasos dados, ya puedes tener otro que haga lo mismo saltándose tu patente.

Por otro lado si patentas cosas demasiado simples (como pequeños algoritmos en los que se basa tu gran algoritmo de compresión) que son necesarias para el funcionamiento de cualquier otra cosa, limitas su uso. Por ejemplo, imagina que patentas la forma de convertir un WAV en un MP3 y solo hay esa forma (por ser muy básica). Automáticamente, si alguien quiere hacer un programa que use esa función, o te paga (si le pones un precio razonable) o no puede hacerlo, limitando la creación de herramientas.
Mira los problemas que tiene Google para hacer su compresor de imagen (VP9 creo que se llama): haga lo que haga, siempre usa una patente de alguien.

Si se usasen con cabeza servirían, pero nunca se han usado con cabeza en temas de informática. Y a la velocidad a la que se mueve este mundo, 2 años es estar obsoleto.

Después de ver tu enlace para VB6 he buscado mejor y he visto que lo que me sonaba era cierto... pero para .NET (o sea, al revés de lo que he puesto).

http://msdn.microsoft.com/en-us/library/aa903254(v=vs.71).aspx

Por lo visto ya en su día (hace 10 años) leí que en .NET era así y se me debió de quedar la cantinela.
También es verdad que en mis programas siempre nombraba explícitamente ByVal o ByRef, sin preocuparme del valor por defecto (no me gustan los valores por defecto, mañana cambia el defecto y se lía).

Si se te da por crear un nuevo Whatsapp, entiendo que con este servicio (de pago, claro) tendrías resuelto el tema de la escalada de peticiones por parte de los clientes al crecer exponencialmente, así solo tendrías que preocuparte de que tu servidor fuese capaz de gestionarlas todas ellas.

Por otro lado, no todo el mundo sabe hacer de todo, así que si te pueden abstraer la parte de comunicaciones para que te puedas centrar en otra parte, bienvenido sea.

Pero claro, en mi ciudad, que es de 100k hab. de poco me podía servir...

Me gusta.