1. Introducción a la Deuda Técnica
Hola, soy Meba. Estoy aquí para hablar sobre el crédito de accesibilidad y cómo pagarlo. Soy un desarrollador frontend que trabaja actualmente en una empresa llamada Mayfell. También soy el organizador de CSSConf Argentina. Hoy estoy aquí para hablar sobre la deuda técnica. La mayoría de las veces, cuando pienso en la deuda técnica, en mi mente aparece este meme. El problema surge cuando comienza a causar problemas en el proceso de desarrollo. Entonces, ¿qué es la deuda técnica? ¿Qué no es la deuda técnica? ¿Es el código malo una deuda técnica? Bueno, en mi humilde opinión, el código malo no es una deuda técnica. En realidad, es una falta. Es una falta de conocimiento. Es una falta de preocupación. Y es una falta de control de calidad. La mayoría de las veces, significa que a alguien no le importa lo que se envía a producción.
Argentina. Y realmente disfruto mucho trabajar con, ya sabes, sistemas de diseño, accesibilidad, y animaciones muy inútiles como la que ves aquí. Hoy estoy aquí para hablar sobre la deuda técnica. La mayoría de las veces, cuando pienso en la deuda técnica, en mi mente aparece este meme. Es como esas situaciones en las que tienes que entregar algo y toda la oficina está en llamas. Y tienes que entregar de todos modos. Entonces, haces lo mejor que puedes mientras finges que nada está ardiendo, nada está en llamas y todo está bien. Así que, creo que usamos memes como mecanismo de afrontamiento, especialmente para la deuda técnica. Estos son mis favoritos. Solo pon la deuda técnica en mi tarjeta de crédito. Moverse rápido y romper cosas, guía de desarrollo frágil. No entiendo por qué tarda tanto en construir una nueva ventana. Y uno de mis favoritos. Arreglemos esto con una solución temporal que creará más problemas a largo plazo. Sí. Para entonces, tendremos que cambiar de tiendas. Entonces, no es deuda técnica si no estás presente cuando se soluciona. O lo que realmente me gusta decir es que no es deuda técnica si no estás presente cuando comienza a causar problemas. Porque tener deuda técnica es normal. El problema surge cuando comienza a causar problemas en el proceso de desarrollo. Entonces, ¿qué es la deuda técnica? ¿Qué no es la deuda técnica? ¿Es el código malo una deuda técnica? Bueno, en mi humilde opinión, el código malo no es una deuda técnica. En realidad, es una falta. Es una falta de conocimiento. Es una falta de preocupación. Y es una falta de control de calidad. La mayoría de las veces, significa que a alguien no le importa lo que se envía a producción. Es muy común culpar al pobre desarrollador junior que
2. Understanding Technical Debt
Pero la realidad es que se supone que debe haber un sistema para ayudar a ese desarrollador junior a evitar enviar código malo a producción. El código malo suele ser más perjudicial que la deuda técnica porque muestra una falta de preocupación por el producto final. La deuda técnica es un compromiso consciente, donde elegimos obtener algo de inmediato a cambio de pagarlo con intereses más adelante. Tomemos un ejemplo con la tematización. Tomamos la decisión consciente de construir una solución rápida para un cliente, aunque resultara en un código basura. Lo arreglaremos más adelante.
acaba de unirse a la empresa porque envió código malo a producción. Pero la realidad es que se supone que debe haber un sistema para ayudar a ese desarrollador junior a evitar enviar código malo a producción. Se supone que debe haber un gerente y otros desarrolladores que deberían poder ayudar a esta persona a evitarlo. Honestamente, creo que el código malo suele ser más perjudicial que la deuda técnica, principalmente porque muestra esta falta de preocupación por el producto final. Y principalmente porque termina siendo un lugar triste donde culpan a los desarrolladores junior por simplemente enviar código feo a producción cuando no debería ser así. Entonces, ¿qué es la deuda técnica si no es código malo? Bueno, la deuda técnica es un compromiso consciente. Y eso es, creo, la parte más importante cuando hablamos de deuda técnica, es que es consciente. Hay una cita que realmente disfruto sobre la deuda técnica, dice que sucede cuando elegimos obtener algo de otra manera inalcanzable de inmediato a cambio de pagarlo con intereses más adelante. Esta es una cita del Sr. Harold Roberts. Si no lo sigues en Twitter, te recomiendo que lo hagas. Habla mucho sobre refactorización y deuda técnica. Es una persona extremadamente amable y también extremadamente conocedora. Así que si lo buscas en YouTube, definitivamente aprenderás mucho. Si miramos esta cita, dice de otra manera inalcanzable de inmediato y pagarlo después, esas son las dos cosas que debemos tener en cuenta cuando hablamos de deuda técnica. Tomemos un ejemplo. Hablemos de la tematización. Pretendamos que somos una empresa que brinda un servicio a diferentes clientes y nuestros clientes utilizan nuestro servicio y nuestro servicio no puede ser personalizado. No tiene ninguna tematización, solo es de este color y ya está. Y tenemos un posible cliente, un cliente importante que dice, si proporcionas una tematización que se parezca a mis colores de marca, entonces seré tu cliente. Entonces, ¿qué sucede en esas situaciones es que generalmente el gerente de proyecto o el gerente de producto se acerca al equipo de desarrollo y dice, bueno, ¿cuál es la estimación para hacer que la tematización suceda? Y los desarrolladores pueden decir, bueno, un par de semanas, tal vez cuatro o cinco semanas si queremos hacerlo bien. Eso significaría que perderíamos al cliente y no querríamos hacer eso. Así que terminamos diciendo, bueno, puedo construir una solución muy rápida solo para este cliente, solo para no perderlo. ¿Y en cuatro o cinco días, qué te parece? Eso suena bien. Eso es genial. Construimos la cosa, importamos todas las cosas, y funciona, y conseguimos al cliente, y eso es genial. Y simplemente codificamos basura. Pero deberías estar muy orgulloso de eso porque es increíble. Teníamos muy buenas razones para crear eso. Tomamos la decisión consciente de decir voy a construir código feo a cambio
3. Repaying Technical Debt and Accessibility
Así que felicidades. Acabas de crear tu primera deuda técnica. ¿La pagarás? Tenemos dos caminos: pagar o pretender que no pasó nada. Si pagamos, necesitamos limpiar y construirlo correctamente. Si pretendemos, acumula intereses y hace que los miembros del equipo estén tristes. Trabajar con bases de código antiguas y defectuosas dificulta el aprendizaje y limita las posibilidades. Necesitamos pagar, abordando específicamente la parte de accesibilidad de la deuda técnica. La accesibilidad a menudo se pospone, lo que resulta en lanzamientos de código que no son accesibles. Podemos consultar el informe de WebAIM para una auditoría anual de accesibilidad.
para conseguir un cliente y luego lo arreglaré. Así que felicidades. Acabas de crear tu primera deuda técnica. Ahora viene la segunda parte. ¿La pagarás? Así que tenemos dos caminos diferentes. Podemos pagar o podemos pretender que no pasó nada. Si pagamos, eso significa que necesitamos tomar un tiempo para sentarnos y limpiar lo que hicimos, y construirlo correctamente, y construirlo también para futuros clientes. Y si pretendemos, eso significa que seguimos trabajando con lo que estábamos trabajando antes de esto, y nunca arreglamos esas cosas importantes. Y lo que podría suceder es que se acumulen intereses. Y también crearás un efecto de bola de nieve. Así que eso significa que tal vez otro cliente llegue y diga: `Oye, ese cliente tiene tematización. Yo también quiero tematización`. Y luego tendrás que hacer todas esas cosas importantes nuevamente, solo para este Cliente B, y tu código empeora. Y luego llega el Cliente C, y dices: `Bueno, está bien, le daré más importancia`. Y empeora, y empeora, y empeora todo el tiempo. Porque si no pagas, se acumularán intereses. Y también hará que los miembros del equipo estén tristes.
No sé tú, pero he trabajado con bases de código muy antiguas y muy defectuosas antes. Y no es una situación muy feliz. Sientes que no estás aprendiendo. No puedes probar cosas nuevas, y no solo los desarrolladores están tristes. También los gerentes de producto y los diseñadores cuando se dan cuenta de que lo que quieren construir no es posible. Así que necesitamos pagar. ¿Y cómo pagamos? Bueno, voy a hablar específicamente de pagar la parte de accessibility|accesibilidad de la deuda técnica. Y dirás, ¿qué? ¿Es accessibility|accesibilidad una deuda técnica? No. Quiero decir, no, no debería serlo, pero en realidad lo es. La realidad es que los usuarios de accessibility|accesibilidad suelen considerarse ciudadanos de segunda clase en la web. Así que, por lo general, se posponen para el futuro a pesar de sus necesidades. Y lo que suele suceder es que terminamos lanzando código que no es accesible porque queremos lanzarlo en un plazo muy ajustado. Podemos echar un vistazo al informe de WebAIM, ellos hacen un informe, un informe anual sobre accessibility|accesibilidad en los primeros un millón de páginas de inicio de la web. Y realizan una prueba muy básica
4. Resultados de las Pruebas de Accesibilidad
En 2022, solo el 3.2% de los sitios web pasaron las pruebas básicas de accesibilidad, lo cual es una ligera mejora respecto al 2.6% del año anterior. Los errores más comunes incluyen la falta de texto alternativo para imágenes, cumplimiento, contraste de colores, etiquetas para entradas, atributos de idioma del documento, botones y enlaces.
WebAIM realiza una auditoría de accesibilidad con pruebas WCAG. Y verifican el texto alternativo, buen contraste, etiquetas para entradas y atributos de idioma del documento. Así que verifican cosas muy simples que se pueden automatizar. Y cada año determinan cuántas de esas un millón de páginas web pasan esas pruebas básicas. Y les pregunto, ¿cuántas creen que las pasaron? ¿Al menos el 20% de ellas? ¿Al menos el 10%? ¿O al menos el 5%? La respuesta es que en 2022, solo el 3.2% las pasaron. Solo 3.2% de los sitios web pasaron esa prueba. Es un poco mejor que el año pasado. El año pasado solo fue el 2.6%. Así que supongo que podemos estar un poco contentos al respecto, pero no demasiado. Los errores más comunes son la falta de texto alternativo para imágenes, falta de cumplimiento, contraste de colores, falta de etiquetas para entradas, atributos de idioma del documento, botones y enlaces.
5. Repaying Accessibility Technical Debt
Muchos sitios web todavía tienen problemas de accesibilidad, como pestañas de marquesina y contenido parpadeante. La falta de accesibilidad a menudo es un compromiso consciente debido a las presiones de los plazos. Para pagar la deuda técnica de accesibilidad, comience con una auditoría básica utilizando herramientas como WAVE o Axe. Cree tareas específicas para abordar los problemas de manera incremental, corrigiendo errores, reconstruyendo componentes rotos y agregando nuevas funciones. Documente los problemas no resueltos y colóquelos en el backlog para reconocer y empoderar al equipo. Evite crear más problemas aprendiendo de los errores e implementando un plan a largo plazo para el cambio cultural.
Muchas de esas cosas generalmente se solucionan con una sola línea de código. También hay un dato curioso que siempre me gusta mencionar. A pesar de ser 2022, 9,152 páginas de inicio tenían una pestaña de marquesina, algo que muchos de ustedes pueden ser demasiado jóvenes para saber qué es. 373 páginas de inicio tenían contenido parpadeante, y eso no debería suceder en 2022. Entonces, ¿por qué sucede esto? Bueno, es una situación en la que la falta de accesibilidad es más a menudo un compromiso consciente. No probamos la accesibilidad y simplemente lanzamos cualquier función en la que estemos trabajando sin hacer una prueba adecuada, porque queremos cumplir con el plazo y el plazo no tuvo en cuenta a las personas con discapacidades. Entonces, ¿cómo comenzamos a pagar? Tenemos dos cosas en mente cuando queremos pagar la deuda técnica de accesibilidad. La primera cosa es cómo pagar la deuda técnica actual, y la segunda cosa es cómo evitar que esto vuelva a suceder, lo cual es un proceso a muy largo plazo. Para la deuda técnica actual, recomiendo encarecidamente realizar una auditoría muy básica, puedes usar WAVE o Axe o cualquier herramienta automatizada que verifique los errores más comunes y anótalos. Y trata de encontrar algo de tiempo libre para mejorarlo lentamente, porque podrías encontrarte con unos 600 problemas, y es como, oh Dios mío, ¿qué hago? Bueno, crea una tarea pequeña y bien definida, como que los contornos de estos elementos no funcionan, como que este menú desplegable no aparece en la navegación por teclado. Crea tareas muy específicas y bien definidas para que puedas trabajar en quizás el 15% de cada sprint. Eso significa que te llevará mucho tiempo solucionarlo, pero está bien, porque estás haciendo trabajo para mejorarlo. Entonces, corriges errores, reconstruyes componentes rotos y también puedes construir nuevas funciones que no tenías antes, como un enlace de navegación de escape. Y cuando no tienes tiempo para arreglar algo, aún lo documentas, aún creas un ticket para ello y lo pones en el backlog. Y sé cómo suena eso, y sé lo que viene a tu mente ahora mismo, es este meme, que significa ponerlo en el backlog para arreglarlo más tarde, ¿verdad? Y es muy común pensar en esto, cuando decimos ponerlo en el backlog, porque parece que nunca lo vamos a arreglar. Pero la realidad es que no se trata realmente de eso, se trata de que no podemos pagar lo que no reconocemos. Y no se trata solo de ti. Es como, está bien, sé que tengo ese problema de accesibilidad. Pero no se trata solo de lo que yo sé. Es importante que todos en el equipo sepan que tengo o que tenemos este problema de accesibilidad. Entonces, cuando hablamos de ponerlo en el backlog, lo que queremos decir es que necesitamos empoderar a todos. Y necesitamos que todos estén en la misma página y sepan cuáles son los problemas de accesibilidad que tenemos y que aún no hemos solucionado. Entonces, por eso lo ponemos en el backlog. Para reconocer que todavía tenemos mucho por hacer. Y luego evitamos crear más. Lo cual es la parte divertida. Porque pasamos por una situación en la que de repente tenemos quizás 600 problemas en una sola página. Entonces, lo que queremos hacer no es solo solucionar eso, sino también aprender de nuestros errores y asegurarnos de no crear el mismo problema nuevamente. Entonces, lo que hacemos es tener un plan para una solución a largo plazo para evitar cometer el mismo error. Todo comienza con un cambio cultural en la empresa,
6. Promoting Accessibility and Design Systems
Lo que necesitamos hacer es encontrar personas que se preocupen, hablar sobre accesibilidad en las reuniones, hacer saber a la gente que es importante y lograr que los CO, CTO y gerentes también se preocupen. Debemos actualizar los procesos, construir pruebas automatizadas y realizar más pruebas manuales. Ejecutar la navegación por teclado en las funciones, trabajar con QA/QE para verificar la accesibilidad e incluir la accesibilidad en las demostraciones internas. Los sistemas de diseño son la clave para solucionar problemas de accesibilidad en todas partes. Sigue a Brad Frost y Sheena Ann para obtener información práctica. Contrata desarrolladores frontend para asegurarte de que la accesibilidad se solucione correctamente. Recuerda, ningún código puede solucionar un mal diseño.
. Lo que necesitamos hacer es encontrar personas que se preocupen. Necesitamos hablar sobre la accesibilidad en las reuniones. Necesitamos hacer saber a la gente que eso es importante. Y necesitamos que los CO, CTO y gerentes también se preocupen por eso para que nosotros, los desarrolladores, tengamos el tiempo para trabajar en ello. Y también para encontrar el tiempo para actualizar los procesos que no están funcionando correctamente. Tal vez podamos comenzar a construir pruebas automatizadas y agregarlas a nuestras herramientas de
CI y
CD. Tal vez también deberíamos comenzar a hacer más pruebas manuales. Entonces, si eres un desarrollador, ejecuta una navegación por teclado en la función en la que estás trabajando solo para asegurarte de que un usuario con problemas de movilidad o que utiliza un lector de pantalla pueda utilizar la función que estás construyendo. O también podemos trabajar con el equipo de
QA o QE y ayudarlos a construir un proceso para verificar la accesibilidad también. Algo más que encontré muy interesante y que ayudó a introducir la idea de accesibilidad en la empresa fue incluirla en las demostraciones internas. En mi empresa anterior, solíamos hacer muchas demostraciones de nuevas funciones en las que estábamos trabajando. Y comenzamos a hacer esas demostraciones con navegación por teclado y también con lectores de pantalla. Y eso puede sonar un poco extraño, pero el objetivo era mostrar que eso es parte de nuestro trabajo. Nosotros, los desarrolladores, los diseñadores, construimos productos para todos. Entonces, debemos probar para todos. Y para hacer que más personas se preocupen por eso y lo sepan, incluirlo en las demostraciones que realiza tu empresa es una muy buena manera. Y lo más hermoso del mundo que te ayudará a solucionar los problemas de accesibilidad de una vez por todas son los sistemas de diseño. Los sistemas de diseño son esta única fuente de verdad donde construyes un componente y muchos productos diferentes utilizan ese componente. Eso significa que si lo haces bien una vez, funcionará bien en todas partes. Eso es increíble. Eso significa solucionar la accesibilidad en tu sistema de diseño y se solucionará automáticamente en todos los demás productos que utilizan ese sistema de diseño. Haz lo que Brad Frost y Sheena Ann dicen. Personas muy inteligentes que trabajan mucho en accesibilidad. Te recomiendo encarecidamente que los busques en Google, los sigas en Twitter y veas sus videos de YouTube, porque comparten mucha información práctica al respecto. Otra cosa que te ayudará a tener casi ningún problema de accesibilidad es contratar desarrolladores
frontend. Y sí, lo digo en serio. La accesibilidad es principalmente un problema
frontend. Eso significa que si quieres solucionarlo de la manera correcta, necesitas desarrolladores
frontend. Y sé que tal vez sintamos que necesitamos ahorrar dinero o tener, ya sabes, estas personas que lo saben todo, y es genial tener algunos desarrolladores full stack, pero si realmente quieres hacerlo bien, necesitas encontrar personas especializadas en accesibilidad, sitios web responsivos y de rendimiento, necesitas encontrar personas especializadas en
frontend.
7. Design Accessibility and Responsibility
Si el diseño no es accesible, tampoco lo será el sitio web. Los flujos de UX deficientes no se pueden solucionar con código. Trabajamos en equipo con desarrolladores, diseñadores, gerentes de producto y gerentes de proyecto. La accesibilidad es responsabilidad de todos. Evitemos la deuda técnica, pero no carguemos a los usuarios con discapacidades.
Y ten en cuenta que ningún código puede solucionar un mal
design. Si el
design no es accesible, tampoco lo será el sitio web. Entonces, si hay flujos de
UX deficientes, no hay forma de que pueda agregar código para solucionarlo. No hay forma de que pueda mejorar este
design con neomorfismo o este otro. Realmente no se puede agregar código, un mal
design o malas decisiones.
Es importante recordar que no estamos en 1999. Trabajamos en equipo. Tenemos desarrolladores, diseñadores, gerentes de producto, gerentes de proyecto. Tenemos personas de calidad que verifican lo que hacemos. Y es importante saber que la accessibility no es solo responsabilidad de una persona, sino de todos y también es responsabilidad de todos. Así que recuerda que no puedes evitar realmente la technical deuda. Eso no es lo que queremos hacer. Pero podemos evitar cargar a los usuarios con discapacidades. Así que muchas gracias.
