[mamcx]

Empezado por Casimiro Notevi

Y que java es un lenguaje de moda, al cabo de unos años pasará de moda y la gente usará otra cosa, pero Delphi es un lenguaje muy amplio que será muy difícil que desaparezca.

Que pena tener que empezar con esto Casimiro, pero es el tipo de argumentos que peor se puede usar (aunque pienso que fue dicho mas por rabia, que da mucha, hay que tener cuidado en como decir las cosas, pa no darle como decimos en mi pais, "papaya" al enemigo).

Java NO ES ni a palos un lenguaje de "moda". Hay que aceptar y entender un hecho irrefutable:

C, C++, Java, JavaScript, C#

Esos son los lenguajes dominantes, POR MUCHO, (y con excepción de JavaScript) tiene muchas cosas que lo hacen *mejores* que Delphi (y los demás), y siendo honestos y sinceros: Son la opción mas "segura" desde el punto de vista de mercado e industria.

Así que atacándolos como si fueran poca cosa o si fueran superfluos no hacemos NADA. Y eso, que todos aqui saben que me molesta enormemente que la familia C sea la dominante.

Otro hecho irrefutable:

No hay mucho desarrollador Delphi, en comparación con otros entornos, y es mas dificil entrar con Delphi ahora que hace años. El gerente que exprese ese tipo de temores, no solo esta justificado sino que ademas es el argumento mas solido que se puede presentar (si y solo si, se compara contra un lenguaje dominante.)

http://www.gorinkai.com/textos/suntzu4.htm

Conoce a tu enemigo y conócete a ti mismo; en cien batallas, nunca saldrás derrotado. Si eres ignorante de tu enemigo pero te conoces a ti mismo, tus oportunidades de ganar o perder son las mismas. Si eres ignorante de tu enemigo y de ti mismo, puedes estar seguro de ser derrotado en cada batalla.

--Sun Tzu

Esto significa que si te enfrentas a un enemigo mas grande y numeroso, y te preguntan que opinas de eso, pues decis: "El enemigo *es* mas grande y numeroso, pero no conoce lo que conocemos y estamos jugando en casa. Asi que asi es como vamos a ganar..."
------

Del mismo libro: No se ataca a un enemigo en sus puntos fuertes, ni se ataca usando los puntos debiles de uno mismo.

Java es mas fuerte que Delphi en: Ecosistema, numero de desarrolladores, ofertas de trabajo, aceptación de la industria, disponibilidad de codigo abierto, documentacion, precio, desempeño en apps servidor, etc.

Ok ?

Ahora maso ya se han expresado parte de la estrategia que puede ganar, asi que:

----

1- Delphi es inferior en aceptacion de la industria/cantidad de "soldados" disponibles.

PERO NO TAN INFERIOR:

http://www.tiobe.com/index.php/conte...pci/index.html

A muchos les choca este indice, pero es de los únicos 3 o 4 que hay, Y es mas que suficiente para hacer captar el punto: Delphi/Pascal es lo suficientemente "Saludable" y esta entre las opciones "no controversiales" a la hora de iniciar un proyecto. Que no se compara a Java/C/C++? Es que esos son tan "adelante" que cualquier otra opción parece mala.

2- El error estrategico #1 es reescribir un software estable:

http://spanish.joelonsoftware.com/Ar...everDoPar.html

Lo hicieron cometiendo el peor error estratégico que una compañía de software puede cometer:

Decidieron reescribir el código desde cero.

Este es el punto MAS importante y el que hay que recalcar. Si estuvieran hablando de pasar Java a Delphi, seria igual el mismo punto. Hay que recalcar al jefe, que es IRREFUTABLE, BIEN CONOCIDO, BIEN DEMOSTRADO que hacer lo que estan pensando hacer es LO MAS IDIOTA DEL MUNDO y que ni Apple, Microsoft, Google ni similares han logrado hacer eso con exito a la primera, y que les ha tomado Años de absorver perdidas importantes para aguantar el golpe.

Si las mejores empresas del mundo en software, con los mas calificados ingenieros no lo han logrado, entonces, menos lo hara esta empresa que ademas, no es de software.

3- Ya que el punto anterior es BIEN SABIDO, el que un programador, consultor, o quien sea no lo sepa, no lo mencione, es una muestra irrefutable que no sabe bien lo que hace, no tiene experiencia, esta ocultando esto pa' ganarse un sueldito. Y por ende:

Querra tu empresa poner a cargo de un proyecto complejo a alguien ASI?

4- No consigo programador en X.

Este es un hecho *irrefutable*. En contraste con conseguir un programador en Java, uno en Delphi es MUCHO mas difícil.

Aceptado este punto, viene lo importante:

El conocimiento del lenguaje/código es *importante*, pero el conocimiento del sistema/logica de negocios acumulado durante todo el proyecto es CRUCIAL.

No solo conseguir un programador sera dificil.

Conseguir uno que *sepa lo que saben los actuales es*:

IMPOSIBLE.

Hay lenguajes mejores que otros, pero pesa mas programador mejor que otros. Y el que ha cumplido con exito en hacer un sistema y sabe las herramientas + la logica es mejor que todo.
---

Cuando se entiende y acepta este hecho, se entiende que la solución de contratar un programador bueno, así sea que sepa, que se yo, visual basic, que aprenda Delphi es trivial en comparacion con que sea capaz de aprender lo necesario para *entender el proyecto actual* y ademas, *hacer uno nuevo* estamos hablando de un desarrollador *senior/experimentado*. No uno cualquiera.

He hecho este proceso varias veces, y he aprendido, a la par que hacer proyectos, repararlos y re-escribirlos (casi toda mi carrera profesional) C#, VB.NET, Delphi, FoxPro, Python, Javascript, Obj-C y muchas otras cosas mas.

Mientras aprender los lenguajes y entornos tiene su dificultad, estamos hablando de meras *semanas* para saber lo suficiente en cualquier lenguaje y unos pocos *meses* para ser competente. Adquirir la habilidad de hacer re-escrituras masivas? Me a tomado *años*, mas de una decada, y apenas en estos dos últimos pienso que he *empezado* a hacer bueno en eso...

Por lo tanto, a este jefe y otros parecido, cual seria un recomendación *saludable* y profesional?


1- Usar nuevas herramientas/lenguajes se hace con proyectos secundarios, no con el principal del que depende la empresa. Eso es como para una maquina, y rehacerla con equipo sin experiencia, sin repuestos y adivinando como es la cosa.

2- Si entra un nuevo programador/consultor, no se le tira a ciegas el proyecto del cual depende la empresa. PRIMERO, se le da un proyecto secundarios a ver como va.

Pondrias a un cirujano desconocido a operar a tus hijos, cuando tienes a la mano expertos y con experiencia? No? Ok. Programadores son lo mismo

3- Si tiene miedo de perder la gente actual: Subale el sueldo y/o tratelos bien. Luego, tengan un plan de como pasar el conocimiento a los nuevos, y/o introduzca mas gente al equipo.

Si tu empresa sufre una catastrofe si ese proyecto se queda sin gente, entonces hay que empezar desde ya.

4- Refactorizar el proyecto actual de forma tal que se puedan reusar los componentes mas importantes, el codigo este limpio, hayan tests, etc. Muy demorado/caro hacer eso?

MAS CARO ES REHACERLO.

Si no tienen estomago para hacer eso, ni empiezen lo otro.

Y este es un paso previo a una reescritura exitosa de un proyecto. La razon? Ya que refactorizar obligaria a repasar el proyecto y recordar porque son las cosas como son y si todo eso sirve o esta estorbando...

5- Si se va a usar otro lenguaje, usarlo para un modulo secundario y utilizar servicios remotos para interfazar. Ir reemplazando progresivamente modulos haste terminar el proceso (esta seria una buena forma de hacerlo)

Donde la embarra la mayoria: Empiezan por lo mas super-facil (hacer un login, por ejemplo) en vez de cojer lo mas dificil...