Jorge Serrano - MVP Visual Developer - Visual Basic - Todos los comentarios

re: Reutilización de código, mantenimiento de aplicaciones (VI)

Juanma — Fri, 19 Apr 2013 12:08:21 GMT

Hola Eduard,

Estoy de acuerdo en el tema de la deuda técnica y en la visión ágil. De hecho que parece fundamental no tratar de dejar todo el código "perfecto", sino invertir el tiempo en solucionar aquello que te está frenando en cada momento (el resto lo dejas bien guardadito y encapsulado y si funciona y no tienes que tocarlo a menudo, estupendo).

A lo me refería es que hay veces que, por intentar correr mucho, te ahogas antes de empezar (no hace falta esperar meses para acumular intereses).

A veces se tarda muy poco en "acabar el desarrollo", para luego pasar por una fase eterna de pruebas hasta tener algo medianamente presentable porque no se han aplicado los más mínimos criterios de calidad a la hora de construir el software.

Por supuesto todo depende mucho del proyecto y del equipo, pero estoy cansado de tratar con proveedores que me dicen "en una semana lo tienes" y es verdad, en una semana lo tengo, pero luego me paso 4 meses hasta que lo puedo poner en producción porque está todo lleno de fallos, y esto lo digo como *cliente* no como desarrollador.

Saludos

re: Reutilización de código, mantenimiento de aplicaciones (VI)

Eduard Tomàs i Avellana — Fri, 19 Apr 2013 10:45:50 GMT

MMmm...

>En tu razonamiento hay una premisa implícita: resulta más rápido y barato hacer software de baja calidad.

Yo SÍ creo que hacer las cosas "mal" puede ayudar a reducir el time-to-market. Pero como todo tiene un precio que se paga. A este precio se le conoce como "deuda tecnológica".

Hacer software de "baja calidad" es más rápido y barato, pero adquiere una deuda tecnológica.

Mientras tengas esta deuda, es decir mientras tu producto no esté "bien" irás pagando los intereses que te genera. Intereses en forma de que arreglar un error te cuesta más tiempo. Que añadir una funcionalidad pasa a ser más complicado, etc, etc.

A medida que inviertes tiempo refactorizando tu código, y así vas "pagando" la deuda contraída, los intereses disminuyen (añadir funcionalidades pasa a ser más fácil, resolver un bug lleva menos tiempo,...).

Y como todas las deudas cuando más se pospone su pago (es decir, si "pasas" de refactorizar el código, "total ya que funciona...") más han crecido los intereses y al final puede llegar a un punto donde ya no es posible asumir su pago, es decir estamos ante una aplicación totalmente inmantenible. Que puede que funcione, pero que no vamos a poder mejorar y donde cuando se detecte un bug será imposible de resolver.

Contraer deuda tecnológica NO es malo. De hecho a veces es imprescindible para sacar producto nuevo (de ahí la visión "agile" de las start-ups), pero debe tenerse presente que se contrae y debe planificarse cuando y como se piensa "pagar" esa deuda.

En resumen: si hago las cosas "mal" quizá saldré antes, pero luego deberé invertir MÁS tiempo en arreglar cada bug o en añadir funcionalidad nueva. Y como no pague la deuda, llegará un punto que mi producto me "explotará".

Así que la conclusión es que se puede hacer algo temporalmente "mal" para salir rápido al mercado, porque es un parche, por lo que sea, pero debemos ser conscientes de ello y luego invertir el tiempo necesario en mejorar el código. Si no lo hacemos, morimos fijo.

Saludos!

re: Reutilización de código, mantenimiento de aplicaciones (VI)

Juanma — Fri, 19 Apr 2013 07:54:13 GMT

En tu razonamiento hay una premisa implícita: resulta más rápido y barato hacer software de baja calidad.

¿Realmente es así?

Ojo, que no estoy diciendo que seguir SOLID a rajatabla y aplicar sobreingeniería a un proyecto sea rentable, pero tampoco tengo muy claro que hacer las cosas "mal" ayude a reducir el time-to-market.

re: Reutilización de código, mantenimiento de aplicaciones (IV)

Juanma — Mon, 15 Apr 2013 09:44:49 GMT

Es interesante la comparación que haces entre SOLID y normalización de bases de datos.

Sobre todo porque al final pasa lo mismo, igual que no siempre la forma óptima de diseñar una base de datos es tenerla completamente normalizada, en el código hay veces en que es preferible violar SOLID para conseguir otros objetivos.

Muy buena la serie, me gusta además que el avance sea "tan lento" porque da tiempo a pensar en cada paso.

re: Reutilización de código, mantenimiento de aplicaciones (II)

Kiquenet — Thu, 11 Apr 2013 08:03:58 GMT

También considero interesante el tema de la compartición - reutilización de código en el mantenimiento de aplicaciones.

Por ejemplo, este caso: se tiene una versión para .net 3.5 y .net 4.0.

Un csproj compilado en .net 3.5 y otro csproj compilado en .net 4.0.

El código fuente está en el proyecto de .net 4.0.

El csproj de .net 3.5 tiene "Links" a los ficheros de código fuente del csproj de .net 4.0.

El problema viene en casos que se utilizan cosas específicas de .NET 4.0, como String.IsNullOrWhiteSpace.

En este caso, ya no compilaría el csproj de .net 3.5.

protected void BtnSSO_Click(object sender, EventArgs e)

{

var tok = new InfoToken();

tok.Idempresa = Convert.ToInt16(this.txtempresa.Text);

tok.IdApp = 4;

tok.Login = (String.IsNullOrWhiteSpace(this.txtUsuario.Text) ? "loginTest" : this.txtUsuario.Text.Trim());

tok.Url = CmbLstUrl.SelectedValue;

...

}

Estaría bien plantearse las alternativas a este caso.

Saludos.

re: Reutilización de código, mantenimiento de aplicaciones (I)

Jorge Serrano — Wed, 10 Apr 2013 13:44:51 GMT

@Juan no pienso borrarlo.

Estas entradas están escritas para que sirvan de reflexión, y tú por tu experiencia has llegado a conclusiones muy acertadas porque ya ves por donde voy.

Todas las ideas, propuestas, comentarios, etc., son bienvenidos vengan en la parte I de este conjunto de entradas o en la VI como verás la semana que viene. ;)

re: Reutilización de código, mantenimiento de aplicaciones (I)

Juan Irigoyen — Tue, 09 Apr 2013 08:47:40 GMT

upsss, lo siento, borra mi comentario, olvídalo todo...

re: Reutilización de código, mantenimiento de aplicaciones (I)

Kiquenet — Tue, 09 Apr 2013 08:00:34 GMT

Coincido con Juan y Jorge.

Ni blanco ni negro, ni complicar las aplicaciones, hacerlos lo más simples posible, y mantenibles a lo largo del tiempo. Lo cual no es fácil.

Seguro que las futuras entregas de Jorge nos aportarán luz y reflexión.

Saludos.

re: Reutilización de código, mantenimiento de aplicaciones (I)

Jorge Serrano — Tue, 09 Apr 2013 07:48:10 GMT

@Juan jajajaja ¡¡¡acabas de matarme el resto de entradas que ya están preparadas y terminadas para salir sólo cuando llegue el momento!!! :)

Aquí aplica también aquella máxima de que no existen balas de plata.

Ni todo tiene porqué ser blanco ni todo tiene porqué ser negro.

Aquí comienza una serie de entradas de tipo reflexión y "mundo ideal", pero que todos sabemos que no tiene porqué ser así. De hecho, estas conclusiones también las trato en otra entrada de la serie.

Hay unas cuantas preparadas que saldrán en los próximos días... pero no te quito la razón en lo que dices porque la tienes, como también sabes que la pueden tener quienes consideren desarrollar siguiendo todos los patrones y principios de diseño existentes.

Siempre digo lo mismo,... cada proyecto informático es único, y lo que para unos es la solución ideal, para otros puede ser el fracaso del proyecto. :)

re: Reutilización de código, mantenimiento de aplicaciones (I)

Juan Irigoyen — Mon, 08 Apr 2013 19:52:01 GMT

@Jorge, me gustaría hacer una reflexión haciendo un poco de abogado del diablo, partiendo de la base de que entiendo que siempre es bueno seguir los principios SOLID, aplicar patrones de diseño, utilizar separación de capas, etc, etc. Pero creo que es también necesario reflexionar sobre el principio Kiss, el programa que pones de ejemplo cumple con los requerimientos que se proponen y entiendo que puede ser una aplicación perfectamente válida, creo que muchas veces somos los desarrolladores los que complicamos las aplicaciones, programas que utilizan WCF sin necesidad pensando en que un día van a ser extensibles y que cuando llega el momento quizás ni siquiera se utilice esta tecnología, aplicación de arquitecturas DDD para programas que solo funcionan en una plataforma, desacoplamiento y otras lindezas que frente a todo hacen que muchas veces las aplicaciones solo sean legibles por auténticos expertos o gente que haya participado en los proyectos desde el inicio, creo que los programadores tendemos a escribir auténticas aberraciones con tal de que nuestra aplicación sea perfecta y al final solo hacemos que complicarlas y entiendo que debemos reflexionar en este punto, creo que muchas veces deberíamos centrarnos en buscar una solución rápida y funcional antes de complicarla sin necesidad. Cuantas veces escribimos código sin necesidad, complicando nuestras aplicaciones, todas las aplicaciones tienen dependencias es imposible eliminarlas todas, en algunos casos como en aplicaciones Web mezclamos un montón de tecnologías, XML, Html, JavaScript, Jquery, Servicios Web, etc, etc, no hay más que ver que la programación tiende a ser cada vez más compleja y difícil y creo que esto es porque los programadores somos los que complicamos los desarrollos pensando en dar solución a muchos problemas sin necesidad. ¿Por qué hacer algo que no necesitamos?. Creo que muchas es mejor centrarse en dar una solución simple y eficaz y pensar menos en el futuro de nuestras aplicaciones, porque muchas veces este no llega o cuando llega la tecnología a utilizar es completamente nueva y rompe con todos nuestros principios haciendo de esta una aplicación menos legible y mantenible.

Un saludo.

re: Reutilización de código, mantenimiento de aplicaciones (I)

Jorge Serrano — Mon, 08 Apr 2013 15:00:52 GMT

@Kiquenet, no conocía las entradas de Javier Suárez. Las echaré un vistazo. ¡Gracias por compartir!. :)

@Juanma, jajajaja me ha hecho mucha gracia lo de "solo superada por copy entrada.txt salida.txt. ¡Que grande!. :)))

Hay varias entradas más en la bandeja de salida.

Irán apareciendo por a poco.

A ver si me da tiempo a sacar todo lo que tengo en mente

Sobre todo a ver si no estoy espeso, lo explico bien, se entiende bien, y resulta interesante.

¡Muchas gracias por comentar!

re: Reutilización de código, mantenimiento de aplicaciones (I)

Juanma — Mon, 08 Apr 2013 14:02:16 GMT

De momento, y con los requisitos que tienes, parece una solución magnífica (solo superada por "copy entrada.txt salida.txt").

YAGNI! :-)

Tengo ganas de ver cómo evoluciona esta serie.

re: Reutilización de código, mantenimiento de aplicaciones (I)

Kiquenet — Mon, 08 Apr 2013 13:50:30 GMT

Jorge, es un tema interesante, puede dar para varios artículos.

En relación a la reutilización y también a la compartición de código, del blog de Javier Suárez:

javiersuarezruiz.wordpress.com/.../windows-phone-tecnicas-para-compartir-codigo-2o-parte

Saludos.

re: GRATIS :: Libro en español sobre Manual de gestión de proyectos ágiles

Ruben — Mon, 11 Mar 2013 20:09:29 GMT

Gracias espero me3 sea útil.

re: Lavando la cara de mi Microsoft Xbox 360 Wireless Racing Wheel

Jorge Serrano — Wed, 06 Feb 2013 11:16:47 GMT

Jajajaja a punto estuve de hacerte caso, pero mi cabezonería se llevó el premio y mi persistencia el triunfo.

No ha quedado mal. :)

re: Lavando la cara de mi Microsoft Xbox 360 Wireless Racing Wheel

Luis Ruiz Pavón — Wed, 06 Feb 2013 09:23:19 GMT

Que grande Jorge!!!

Doy fe de como vino el volante, porque yo mismo te dije que lo devolvieses y al día siguiente me quedé flipado!!! Vamos, el de bricomanía a tu lado un aficionado...

Un saludo!!!

re: Usando Visual Studio, LINQPad 4 y NHibernate Profile (versión paso a paso)

Ernesto — Fri, 01 Feb 2013 00:04:10 GMT

Y... algo similar pero con EF? :)

re: ¿Fidelidad de los clientes con las empresas o fidelidad de las empresas con los clientes?

Ernesto — Thu, 31 Jan 2013 21:57:04 GMT

Interesante lo que planteas, pero te cuento algo curioso que esta pasando en Peru que trastoca tus esquemas, sobre todo por como están generando "fidelidad" de mala manera.

1er ejemplo) Hace unos años Bellsouth tuvo que vender sus operaciones en Latam y claro.. las compro Telefonica (2004), el caso es que hasta el año pasado hay clientes que se resisten "con todo" a cualquier regalo (equipos) todo por conservar los planes de facturación que les vendió Bellsouth, ya que los planes de TdP son peores.

2do ejemplo) A principios del 2011 (cuando regrese a Lima), Claro y Movistar ofrecían planes de datos de 3GB (dicen que uno los tenia ilimitados pero no los llegue a ver), el caso es que durante el 2011 los nuevos planes empezaron a ser de 1GB para el mismo precio, y ahora la cosa es peor 750MB para la tarifa de los antiguos 3GB, consecuencia: quienes contrataron hasta principios del 2011 no aceptan renovación de smartphones y prefieren comprar smartphones liberados pues llega a salir mas a cuenta....

Y por lo mismo.... aun dudo de comprarme un smartphone pues con 750MB ya me diras

re: ¿Fidelidad de los clientes con las empresas o fidelidad de las empresas con los clientes?

José Ignacio Merino — Thu, 31 Jan 2013 10:01:42 GMT

@Juan, @Julio

No siempre hay que fidelizar. Antes de plantear una estrategia de fidelización tienes que hacer una clasificación de clientes en A, B y C.

No tiene porqué ser únicamente en función de rentabilidad (estoy seguro que si consigues de cliente para un trabajito pequeño a una empresa del IBEX-35, aunque por su nivel de facturación sea cliente C, tu lo considerarás como A por el potencial).

Así que tomas una serie de factores (facturación, rentabilidad, potencialidad, ...), los mezclas y obtienes tu clasificación de clientes. Ahí metes el corte donde quieras y dices "de aquí para arriba A, los del medio B y los de aquí para abajo C". Y a partir de ahí estableces la estrategia de fidelización.

Te recomiendo fidelizar a los A. A los clientes B y a los C pues depende. La fidelización cuesta dinero y la pregunta que te tienes que hacer es "cuántas cenas voy a pagar como máximo a la chica antes de conseguir que me de un beso". Si la chica es A le pago como mucho 5 cenas, si es B, 3 cenas y si no es C me tiene que prometer que habrá beso, si no, ni me molesto.

La clasificación ABC de la chicas será una combinación de factores en los que no prima únicamente la belleza, sino la inteligencia, que tenga cosas afines a ti y puedas charlar con ella, lo divertida que sea, que puedas intuir que es una fiera en la cama, ... (perdonadme el ejemplo, si alguna chica considera que esto es un ejemplo sexista, que le de la vuelta y piense en un chico).

re: ¿Fidelidad de los clientes con las empresas o fidelidad de las empresas con los clientes?

José Ignacio Merino — Thu, 31 Jan 2013 09:39:46 GMT

Efectivamente en telefonía hay una tasa de cambio muy grande, pero era permitido por las compañías para poder disponer de una red de distribuidores.

Cuando tu mandas a la mierda a la compañía de móvil, lo que haces es irte a un punto de venta de la competencia y allí pides ofertas y terminales. Si la operación la haces y te portas, ese distribuidor recibe un dinero por la venta.

Si todos los clientes estuviesen fidelizados, al final no vas al distribuidor porque no te hace falta cambiar, estos no reciben un duro y al final tienen que acabar cerrando.

El que un distribuidor de una compañía cierre en un pueblo (o en una zona) implica que dicha compañía deja de tener visibilidad ahí y por tanto con el tiempo acaban siendo arrastrados el resto de clientes que tiene por el resto de puntos de venta de las compañías de la competencia que hayan quedado ahí.

Así pues esa tasa de cambio tan alta era para mantener la red comercial. Lo que pasaba era que abrir una tienda de móviles fuese muy rentable y surgían como hongos. Ahora no es tan rentable debido a que las 2 grandes están fidelizando a sus clientes.

La gran perjudicada será Vodafone, pues Movistar con su pack de Móvil+ADSL a precio reducido ha conseguido que la gente contrate en su punto de venta. Así que a poco que te fijes, verás como comenzarán a cerrar tiendas (principalmente Vodafone y en menor medida Movistar).

Por otro lado, como tu bien dices, los clientes no son para siempre. Las compañías suelen calcular el tiempo de vida medio de un cliente y la rentabilidad que le van a sacar. Cuando pasa de ese tiempo de vida medio, es inútil retenerte porque ya te han sacado lo que ellos querían sacarte.

Los productos tienen su ciclo de vida: estrella (sale el producto y el crecimiento es muy fuerte, la rentabilidad pequeña por el gran esfuerzo de expansión que tienes que hacer), vaca (el crecimiento del producto es menor pero tienes amortizada la expansión por lo que los beneficios son muy altos) y perro (el producto va en declive y los beneficios comienzan a caer).

No tiene sentido fidelizar al cliente en un producto perro, ni en uno estrella. Únicamente en uno vaca. Piensa ahora por un momento: ¿en qué ciclo de vida está actualmente la telefonía móvil?

Y luego tienes la venta cruzada. Hay compañías que donde sacan realmente no es en la venta del producto en si, sino en la venta de otros productos que les puedas hacer. Así que te fidelizan desde el primer momento en productos en los que no le ves mucho sentido. Por eso fueron tan amables en HP y te regalaron una pieza que tan sólo los gastos de envío eran mayores que el beneficio que hayan podido sacar con su venta (duplicando o incluso triplicando el beneficio) porque eres infinitamente más rentable por la venta de los cartuchos de tinta.

Ese es también el tema de los bancos, donde lo importante para ellos es que te vendan el mayor número de productos (lo llaman vinculación). Así que si domicilias recibos, tienes nómina, te regalan las tarjetas, te dan un menor diferencial en los créditos y te dan mayor tipo de interés en los depósitos/planes de pensiones.

Todo depende del sector, la cultura de la empresa, el tipo de producto. No hay reglas fijas en esto y más que una ciencia es un arte.