La versión 1.0 de slash tenía el problema de ser una evolución natural de las primeras versiones de slash, con alguna pequeña reorganización en el código y la introducción de nuevos servicios. Pero en esencia, se basaba en la misma arquitectura que nació de un proyecto en desarrollo contínuo y regido por las necesidades del día a día de Slashdot. Los principales problemas que comenzaron a ser serios obstáculos en el desarrollo de slash fueron:
El código HTML que se mostraba al usuario del sitio aparecía repartido por varios servlets Perl (cgis deasrrollados en Perl) así como en alguna librería e incluso en la base de datos. La lógica de visualización y del programa estaban mezcladas.
No existía una interfaz clara de acceso a base de datos, apareciendo peticiones SQL en el código, peticiones además dependientes de MySQL.
Existía una gran librería en la que se metía toda la lógica del código, dificultando su evolución y mantenimiento.
La idea de separa de forma clara las capas de visualización, acceso a datas y lógica de la aplicación se hizo cada vez más fuerte y, tras la publicación de la última versión 1.x de slash se tomó la determinación de llevar a cabo una gran transformación del sistema, utilizando un sistema de plantillas, creando una API de acceso a datos, y diviendo la gran librerías Slash.pm en varias librerías que resumían distintas partes de la lógica del sistema. A esta nueva versión se la llamó Bender y es slash 2.0, de la que vamos a hablar en la ponencia.