Deuda Técnica: Disminuirla o Evitarla?

Hace unas semanas me tocó hacer una presentación en el Up de Arquitectura de una gran empresa acá en Chile, que se dedica a los seguros, para su departamento de informática. El tema era el desarrollo seguro y tal como dije ese día una de las formas de hacer desarrollo de software seguro, es ir reduciendo la deuda técnica.

La verdad es que la deuda técnica, es un concepto-realidad, con el que debemos pelear quienes nos dedicamos al desarrollo de software, mas bien a diario y por diferentes motivos, muchas veces heredada de proyectos anteriores y otras, de una manera intencionada, dado que el time to market nos hace generarla. Pero qué debemos hacer con ella? La verdad es que como decía a veces es imposible evitarla, pero lo que sí debemos hacer es disminuirla y hoy de manera urgente. La deuda técnica no es de por sí mala. Si nos dedicáramos a eliminarla y dejarla en cero cada vez que lanzamos un nuevo producto de software, lo más probable es que nos demoremos más tiempo en salir y el vecino nos gane el quien vive y es por esto que en tiempos de agilidad, es posible hacer que la deuda sea cada disminuida y afrontada en cada iteración. Esto, como leí en algún lugar es como endeudarse para comprar una casa, si nos ponemos a juntar peso a peso para comprar una, es probable que tardemos años en comprarla o bien el precio cambie y nunca nos alcance el dinero, pero si decidimos endeudarnos, de manera consciente y ordenada, tendremos que amortizar mes a mes y en un periodo acotado de tiempo.

 

Arquitectura de Software: Debe el arquitecto programar?

El arquitecto de software, tiene una gran responsabilidad sobre el sistema, debe diseñarlo para que durante su ciclo de vida sea capaz de ser resistente a los cambios, sin que su mantenibilidad y también su performance se vean afectados. En tiempos de agilidad, la arquitectura de software se torna aún más importante pues los componentes deben ser cada vez más livianos, mantenibles de manera independiente, pero sin perder la capacidad de conectarse con el resto de los componentes,  y desde luego de separarse del resto sin romper el flujo operacional.

Dentro de toda esa responsabilidad también al arquitecto le competen las normativas de desarrollo, estándares de codificación, selección de patrones de diseño, arquetipos, normas de desarrollo seguro y selección de lenguajes (que por cierto mientras más agnóstico mejor) , pero debe también programar?

A mí modo de pensar, sí, el arquitecto siempre debe programar, quizás no el 100% del proyecto, pero al menos los arquetipos, debe también programar en los lenguajes que propone pues es necesario que se forme una idea/impresión de las capacidades , ventajas y desventajas de ellos, para así decidir que piezas de software construye con qué o cual lenguaje, para así proveer del mejor stack de soluciones a su equipo. Debe también programar para poder revisar si sus políticas se están utilizando de forma correcta y validar si son efectivas o si debe modificarlas. Hacer inspecciones de código que le permitan corroborar todo lo que planificó en el diseño se cumple y es efectivo.

El arquitecto no puede dejar de aprender, investigar y probar, así y sólo así podrá aportar de buena forma a su organización. Es quien debe tener la visión tecnológica y si deja de hacerlo se volverá cada vez menos agnóstico a la tecnología dejando a la organización cada vez más dependiente y menos resistente a los cambios, transformándose él en un riesgo para ella.

¿Cómo iniciar un podcast?

Definitivamente el audio sigue siendo una buena forma comunicar, aun cuándo en la época de youtube, todos prefieren (preferimos) el video, pero el primero sigue siendo más fácil de generar, más rápido y casi tan efectivo, además de fácil de compartir.

Comenzar un podcast es sencillo y necesitas básicamente 4 cosas: Ganas, un tema, un micrófono y un lugar dónde compartir.

El Tema

Elegir el tema de que irá tu podcast es muy importante, debes buscar algo que te guste, sepas y quieras explicar y compartir tus conocimientos y que desde luego tengas para hacer múltiples capítulos.

Cada capítulo deberás planificarlo, escribirlo y usar esos apuntes cuando hables para así no perderte, te aseguro de que será de mucha ayuda.

El Micrófono para tu Podcast

El audio es vital para el éxito de tu podcast, si no se entiende bien lo que dices, si se escucha mal, nadie querrá seguir tus audios, definitivamente un mal audio será perjudicial y es que es evidente es el medio por el cual tu mensaje va a llegar y debe ser limpio. Para esto la elección de tu micrófono es fundamental.

Para esto hay varios ejemplos  y a diferentes precios, entre los que destacan.

Como pueden ver hay muchas opciones, y fáciles de utilizar, ya que son usb, excepto el BM 800,

Dónde Compartir

Aquí también hay varios lugares especializados, lo que debes preguntarte es si quieres pagar o si quieres algo gratuito, por mi parte creo que lo principal es que el lugar que selecciones debe generar un feed rss de modo que puedas compartir las entradas del podcast de manera simple y por ejemplo enganchar con itunes.

Mis elecciones para compartir son ivoox y spreaker, ambos tienen versiones gratuitas y de pago.

La elección es tuya pero ciertamente el podcast sigue siendo una excelente opción para comunicar tus ideas.

 

¿Cómo elegir audífonos?

Comprar audífonos siempre ha sido una elección personal, no hay un estándar para decir si uno suena mejor que otro, aun cuando definitivamente muchas veces hay consenso de que algunos definitivamente suenan pésimo. Lo que sí es cierto es que con el tiempo puedes distinguir marcas con las que te sientes mejor con su sonido y otras con las que definitivamente no «comulgas».

Es por esto que llegar a la tienda de audífonos como quien elige calcetines, no es algo que, al menos yo haría, sobre todo porque los audífonos no son algo barato y serán tus compañeros, muchas horas al día, por muchos días, por tanto además es un dispositivo con el que te debes sentir cómodo, eso si por ejemplo eres informático como yo.

Hay varias cosas que yo haría para elegir un buen par de audífonos y mi lista es la siguiente:

  • Establecer el presupuesto: Bueno esto es importante y lo que nos hará muchas veces tomar la decisión final, establecer un desde y hasta nos dará un abanico de posibles candidatos.
  • Evaluar los candidatos: Una vez que establecimos la cota de presupuesto veremos que podemos adquirir con ese presupuesto y ver cuales de los múltiples participantes en el mercado nos gustan más.
  • Ver videos de youtube con información: Bueno pues esto para mí esto es fundamental, ver opiniones de usuarios, unboxings y experiencias, análisis de características, es definitivamente algo que me hará decantar por 2 candidatos y ayudar a tomar la mejor elección.
  • Ir a la tienda y pedir probarlos: Este es un paso muy importante y sobre todo probarlos con tú música y tu dispositivo que escuchas a diario (se vale el celular)
  • Preocuparse de cosas importantes para el paso de los años: Que tenga cable intercambiable y que las esponjas de las orejas tb.

¿Por qué he dejado de programar en Android?

Comencé en Android en el verano de 2009 cuando aún en Chile no llegaban los teléfonos para poder hacer pruebas, cuando la info en foros de internet era poca o casi nada, y donde lo único que quedaba era el ensayo y error.
De esa práctica laboral, salió mi tesis y también mis primeros trabajos como profesional luego de salir de la universidad. En verdad y para ser sincero le debo mucho a Android, me ha dado de comer por bastantes años, pero también es cierto que me ha dado muchos y bastantes dolores de cabeza, sobre todo cuando me ha tocado hacer aplicaciones de corte masivo y que deben llegar a muchos tipos de público.

Android es un sistema operativo que creció muchísimo y logró penetrar en todo tipo de segmento de usuario, en muchos fabricantes y por lo mismo en espectro muy grande de tipos de teléfonos con las más diversas características en cuanto a componentes de hardware se refiere, pero es aquí donde nace la dificultad para el equipo de desarrollo.

Hoy en día la última versión de Android es la 9 (Pie), pero resulta que aún hay teléfonos circulando que tienen la versión 5 (lollipop) que fue lanzada en 2014, eso es 4 años atrás, la versión más usada es la 6 con un 28%, la versión 8 a febrero de 2018 tenía un 1.1% de cuota de instalación. Pues bien eso te obliga a hacer aplicaciones que deben abarcar diferencias de hardware enormes, pero peor aun no es que sean 5 o 6 equipos, cuando subes una app de este estilo a play store, la tienda te dice que tu aplicación es instalable en miles!!! sí miles! de dispositivos distintos. Cómo probar? es cierto existen técnicas pero ten por seguro que lo más probable es que exista un conjunto muy grande de dispositivos en que la app no funcione del todo bien y otra cosa importante, una cosa es que sea instalable, otra es que corra, lo que son dos cosas diametralmente distintas.

Esto es un problema y que debe terminar, ya sea por presión de la comunidad de desarrolladores o porque Google decida de una buena vez alinear a los fabricantes, a estandarizar la memoria, potencia de procesador y por sobre todo las actualizaciones, eliminando el bloatware y capas de personalización.

Es cierto las diferencias de hardware hacen que los fabricantes compitan y que no se transformen en un comoditie, pero al menos que se pongan de acuerdo en las actualizaciones y que se le de soporte a un equipo por más tiempo del que se le da hoy en día. Vamos que Apple lo hace, el Iphone 5c es un equipo viejo y hace no mucho le han seguido dando soporte.

 

 

Es bueno fotografiar siempre en RAW?


En este episodio del podcast quise comentar acerca de lo bueno y lo malo de fotografiar en raw.
La verdad es que como comento, el raw tiene grandes ventajas, pero quizás una gran desventaja y es que no siempre estamos dispuestos a revelar y por eso dejamos muchas fotos, en su mayoría personales, en el olvido, guardadas haciendo espacio en disco, pero sin disfrutarlas.

Les dejo el capítulo para que lo escuchen y escriban su opinión.

 

Usando Heroku para proyectos en la nube

Desde hace unos meses he estado trabajando en un proyecto, en donde como equipo se decidió que el aplicativo funcionaría por completo en la nube. Dado que el equipo de trabajo es pequeño y nuestra función y dedicación principal es el desarrollo de software, como producto y tampoco tenemos el tiempo es que decidimos que PaaS era nuestra opción. De entre varias optamos por Heroku, hoy quiero ofrecer mis comentarios acerca de mi experiencia, aún cuando no estamos 100% en producción.

Lo primero que debo destacar es que si eres un desarrollador y sólo te interesa tu producto y su despliegue y no quieres preocuparte de nada más, entonces, deberías considerar Heroku como tu plataforma. La instalación de tu aplicación desde tu local hasta tu ambiente productivo es muy sencilla, es cosa de un par de comandos y está.
Las configuraciones iniciales también son muy fáciles de hacer, implementar una base de datos será cuestión de seleccionar, nombrar y aceptar. Quizás la menor ventaja está en la configuración de memoria, en donde las diferencias de precios altas y las escalas son muy básicas, 25 dólares por 1 gb de ram es muy poco y la aplicación genera prontamente mucha latencia, eso hace que la capacidad de resistir grandes cargas sea complicado, salvo si lo que piensas hacer sea basado en microservicios y todo sea muy muy atómico.

A mi modo de ver Heroku no es aún un ambiente productivo, si no mas bien un ambiente para hacer prototipos, MVP o simplemente test, pero su modo de escalamiento no está preparado para poder soportar mucha carga, por un precio que te sea cómodo de pagar.

 

BMC logoBuy me a coffee