Artículo: El mito de la productividad de los desarrolladores


(Camilo) #1

El artículo habla sobre la productividad de un desarrollador y por qué es practicamente imposible de medir. Como tampoco es posible comparar objetivamente la productividad de un desarrollador con la de otro.


(Edgard Pineda) #2

Excelente artículo. El problema es lograr convencer o mostrar este planteamiento a los ingenieros industriales o en general a los jefes o gerentes que no son técnicos o no saben de computación más que a nivel de usuario.
Creo que prepararé una presentación basada en este artículo para tenerlo siempre “bajo la manga” a la hora de recibir comentarios como “los desarrolladores tienen que ser más productivos!” de parte de personas que no tienen idea de lo que es desarrollar, y ayudarlos a tener mejor visión sobre este tema.


(Guillermo Schwarz) #3

“A good developer is able to take a high-level problem, see best way to break it down, and create the correct levels of abstraction, all while keeping the code readable and maintainable for other developers. This also explains why some people are 10x performers, and some people get so frustrated with programming that they give up. Some people have curated, or have a natural talent for, thinking at this extreme level of detail. Some people can intuit things that others will never discover – even if they had all the time in the world. This is the nature of knowledge work.”

Falta mencionar que en la mayoría de los proyectos la jefatura es “lazy” y mide solamente lo que es fácil de medir, es decir te asignan 2 o 3 tareas y miden sólo esas, como un muestreo, de manera que es imposible saber la productividad real de un desarrollador, porque cuando sabe o se da cuenta que están midiendo se apura.

Es archi conocido el método de no hacer nada hasta que no te están midiendo, así estás descansado y puedes terminar la tarea en tiempo record.

Cuando las metas son muy difíciles, todo el mundo hace trampa.

Si eres un manager ¿cómo evitas que te hagan trampa?

Fácil; mides todo. Mides los casos de uso devueltos a los anañistas porque estaban incompletos o inconsistentes. Mides cada una de las tareas de acuerdo a las estimaciones de los mismos desarrolladores, y lo haces de manera automática usando el issue tracker, mides cuándo va a estar listo el proyecto si las tareas que hoy están terminadas son terminadas a la velocidad de cada developer, mides cuántas tareas no están estimadas, mides a qué velocidad aparecen defectos (típicamente por cada tarea terminada, aparece un defecto que toma la mitad del tiempo), etc.

Si por cada tarea termnada aparece un nuevo defecto que toma la mitad del tiempo, ¿cuándo terminará el proyecto?

sum(1,n,1/i) = 2

o sea toma el doble, lo que experimentalmente sabemos que es cierto, todos los proyectos POR LO MENOS toman el doble de tiempo.

Más aún si ciertos programadores estrella pasan la aplanadora y la retroexcavadora por el código para terminar rápido su feature… todos los conocemos… cobran caro porque “programan rápido” pero por alguna razón el proyecto nunca termina y se abandona.

¿Solución?

Unit tests y functional test.

¿Cómo convencer a un ingeniero industrial o comercial?

En la práctica me ha resultado imposible. Teóricamente uno entiende que un ingeniero industrial está bien capacitado para dirigir una fábrica, la ingeniería industrial fue fundada por Frederick Taylor, quien mejoraba los procesos en una fábrica, trabajando codo a codo con los obreros, de hecho la primera práctica de los industriales consiste justamente en eso: trabajar como obrero, para pasar por lo mismo que Frederick Taylor.

Los procesos en una fábrica son todos iguales. Para producir siempre el mismo auto tienes que seguir perfectamente los mismo pasos.

En el caso del software si estás escribiendo siempre el mismo código: Qué desperdicio.

¿Te imaginas a un ingeniero industrial dirigiendo un equipo de arquitectos?

Renunciaráin en masa, porque los arquitectos saben que su trabajo es inherentemente diferente del de los obreros. Su tu trabajo es diseñar, tener a un perro bulldog respirándote en la nuca preguntándote cuando vas a terminar, definitivamente no es la mjeor manera de dirigir a un equipo de arquitectos, mucho menos si le piden a cada uno diseñar lo mismo (qie es la úncia manera de comparar sus habilidades).

Lo que los ingenieros requieren es trabajar en ambientes que inspiren la innovación. Crear cosas nuevas, nuevos sistemas operativos, nuevos lenguajes, nuevas bibliotecas, simplificar el proceso de desarrollo, hacer que la gente se sienta orgullosa de lo que hace, ingenieros viejos entrenando a ingenieros novatos, no “jefes” que no tienen idea y que te dan consejos tan estúpidos como “baja la calidad para terminar antes”, “trabaja más horas para terminar a tiempo”, etc.

Eso baja la productividad x100.

Las empresas más productivas cuestionan las ideas que flotan en el aire.

La mayor productividad implica que estoy desocupado el 80% del tiempo. Si no, ¿de qué productividad me hablan? ¿Estoy resulviendo bugs todo el tiempo? Eso es productividad = 0, la productividad debe ser medida por “features”, mientras que los bugs, si existen, son automáticamente productividad negativa.

Y estamos en una industria que está tan acostumbrada a la productividad negativa que hablar de productividad sólo se entiende como pagar sueldos aún más bajos y horas extras obligatorias y gratuitas… el código luego uno lo mira y se da cuenta que hay más defectos que líneas de código…

¿Cómo hacemos para no tener bugs?

Code conventions, code review, unit testing, functional testing, continuous integration.

¿Y respecto de las horas trabajadas?

Debo explicar algo antes de dar mi opinión. El mismo problema lo puedo resolver con 2 líneas de código o con 200. Eso ya lo dice el texto. pero lo que no dice es que el código es sólo costo. Lo que importa es la funcionalidad. Eso es lo que tiene valor. De modo que un análisis costo-beneficio nos dice que es mucho mejor la solución de 2 líneas de código.

¿Qué tiene que ver esto con las horas trabajadas?

Mientras menos horas trabajes, eres más productivo. Y esto puede ser medido. Después de las primeras 5 horas de trabajo diarias, produces más bugs que features. El cerebro se seca, debes recostarte para que se humedezca y dejar de pensar, por media hora, y luego retomar. pero no puedes mantener la concentración en temas que requieren mucha CPU como programar.

Fíjate que en Chile está prohibido que un conductor de bus interprovincial maneje por más de 5 horas seguidas, ¿porqué será? No creo que las 5 horas sean antojadizas, se lo deben haber pedido a médicos que saben, que han medido cuánto tiempo te puedes concentrar en algo que “usa el cerebelo”.

El cerebelo es el cerebro de los reptiles, el más básico. El cerebro de los mamíferos es muy superior. Y el humano aún más. ¿Qué te hace pensar que el cerebro humano puede funcionar más de 5 horas seguidas?

La mayor parte de los trabajos sólo exigen concentrarse por minutos, a veces un par de horas, y el nivel de concentración no es mayor que el del conductor del autobus.

Los trabajos de desarrollo requieren 100%R de concentración y además terminas hasta soñando con el trabajo, generalmente las personas normales tienen entre 3 y 5 sueños.

Piensa en eso.


(Camilo) #4

muy buena respuesta amigo Guillermo. :+1:


(Guillermo Schwarz) #5

En realidad el problema no es que un desarrollador sea más rápido que otro.

El problema es ¿poequé tienes 2 desarrolladores haciendo lo mismo?

Si no estan haciendo lo mismo, entonces ¿cómo sabes que uno es más
rápido que otro?

Todo se resume en eliminar el código repetido, creando abstracciones.
Esa es la verdadera productividad y dónde te diría que el 80% de los
programadores fallan y el 100% de las jefaturas.

Porque en Chile insisten en que tienes jefes, y eso es mentira. Lo que
tienes son clientes, te pagan por hacer algo pero no tienen la menor
idea de cómo hacerlo. Eso Peter Drucker lo define como “cliente” y te
dice que debes renunciar y cobrar lo que realmente vale lo que estás
haciendo.

Si te fijas un poco ¿porqué hay tanto desarrollador?

Porque el “cliente” sabe esto. Entonces contrata a uno, luego contrata
a otro, luego lo reemplaza por otro, y así sucesivamente y te
encuentras con cosas como que:

  1. El 90% del codigo está repetido.
  2. Hay cero abstracción.
  3. Los requerimientos son del tipo toma el archivo PLCUA y compáralo
    con el resultado del archivo PXCLC. Esos no son verdaderos
    requerimientos, porque terminas con más dudas que las que responde.
    Cualquier intento por clarificar qué significa sigue con más términos
    como esos, una intrincada web de preconceptos sin definiciones reales.
  4. Agarran el fuente de jBPM y lo chantan dentro del proyecto.
  5. No hay control de versiones.
  6. De pronto te das cuenta que el jBPM está modificado y depende del
    resto del proyecto.
  7. Cada parte del proyecto se compila de manera diferente. Unas con
    gradle, otras con maven, otras con ant, otras con el IDE y luego se
    reemplazan algunos archivos a mano.
  8. No hay manejo de excepciones. Si hay errores, se los traga.
  9. No hay tests unitarios.

Entonces te das cuenta que todo fue hecho a la rápida. El mayor
problema de los proyectos de hoy es que no tienen tests unitarios, se
los saltan, ese es un indicativo de programadores con una grave
deficiencia mental. Pero pucha que trabajan rápido.

Luego vienen los errores en producción, que obviamente son al menos
100 veces más difíciles de corregir que corregir los tests unitarios.

He visto empresas tan ridículas que un tercio de tu sueldo depende de
que termines a tiempo… y no tienen tests unitarios…

Obviamente la gerencia es cabeza hueca. Le estás diciendo a los
dearrolladores que se apuren o no tienen sueldo (bueno podrán tomar
micro, ir a dormir a su casa o comer, pero no las 3 cosas). ¿Cómo
crees que se sienten esos tipos?

Además si tienes trabajando a niñitos de 25 años probablemente no
tienen una familia que mantener, y el dinero lo usas para carretear,
pero ¿cómo le dices a tus hijos o a tu esposa que este mes no vamos a
comer? No es por nada, pero un jefe así es un estúpido. Obviamente la
gente va a hacer trampa y se va a saltar los tests unitarios y lo más
probable es que a la menor oportunidad se van a ir a una empresa de
verdad.

Además ¿quién entiende que no haya code conventions para hacer los
code reviews? ¿Y qué sacas con hacer code review si no tienes tests
unitarios? Lo que te dijo pepito luego lo deshace juanito, porque los
code reviews no quedan registrados dentro del control de versiones,
los tests unitarios sí.

En resumen, si una empresa no está haciendo XP está perdiendo el
tiempo. Y según dicen los XPers los problemas casi nunca son técnicos,
son siempre organizacionales, de modo que el detector de problemas
debe estar siempre por el lado organizacional, porque si te fijas en
la universidad pasas 6 años aprendiendo qué? programar? Lo dudo, no
tuve ningún curso de programación, a lo más se programa para aprender
otra cosa.

Entonces qué aprendiste? A diseñar? Tampoco. No recuerdo ningún curso
en que se explicara como se hace un diseño de software, eso lo
aprendes en la pega, echando a perder. Y recuerdo los consejos que
daban los profesores: “No escriban muchas clases”. Les hicimos caso y
terminamos con tremendas clases, que tenían demasiadas
"responsabilidades" y por lo tanto no eran reusables. De modo que las
partimos en muchas clases chicas y esas sí eran reusables. Luego leí a
Bertran Meyer: “Si tu diseño es muy complejo, agrega más clases”. La
información está, el problema era que no había llegado a la querida
alma mater.

Aprendiste entonces a administrar proyectos? Ni en tus sueños.

De partida no puedes administrar lo que no puedes medir. ¿Y qué
palancas tienes para adminsitrar un proyecto? ¿Contratar más gente?
¿Pagarles bonos? Ya vimos que eso hace que trabajen peor.

Si las personas buscan trabajos estables, ¿qué puede ser más estable
que no hacer nada? Y lo segundo más estable es destruir la
funcionalidad 1 y 2 creando la funcionalidad 3. Si son 100
funcionalidades, me voy a entretener una eternidad. Algunos
programadores lo hacensin querer. He conocido a otros que lo hacen a
propósito y se vanaglorian de ello.

¿Cómo controlas a esos tipos? Tests unitarios. No hay otra respuesta.

Mira la cara de “me voy a desmayar” cuando le dices a un programador
"acá va todo con tests unitarios". Es como si se estuvieran pudriendo
por dentro. E inmediatamente dicen “hay cosas que conviene hacerlas
sin tests unitarios”. ¿Ah, si? ¿Cuáles? Y entonces te cuentan cuáles
son los temas que no cachan bien. JAJAJAJA

Ese secreto me lo dijo uno de los creadores de XP, el año 2000. Y se
cumple implacablemente bien. De hecho a míme pasaba con las interfaces
de usuario, pensaba que era imposible probarlas de manera
automatizada. Se puede, sólo tienes que aprender cómo.

Incluso he creado paneles donde poner las interfaces de usuario y
probarlas a mano, te demoras un par de días, pero te ahorras meses de
debug.

Esas cosas debe saberlas un jefe. Todo debe tener test. Hasta los
requerimientos deben ser probados, ojalá en el momento que te los
dicen. De hecho de eso se trata el análisis, que no te engrupan con
requerimientos falsos. En una de las metodologías ágiles, llamada
DSDM, existe “requirements scrubbing” y es exactamente lo que se
supone que debes hacer en el análisis de requerimientos, que en Chile
todo el mundo se lo salta y por eso confunden análisis con diseño. Por
eso siempre digo, a modo de mantra, en cada proyecto, “requerimientos
reales”. Hay gente que me discute que en realidad son “necesidades
reales”. Puede ser, pero las necesidades son aquellas cosas “sine qua
non”, es decir, “sin las cuáles no”, y no todos los requerimientos son
necesarios (o críticos), algunos son de valor agregado.

Por ejemplo si estás vendiendo un auto, las ruedas, el motor, los
asientos, el manubrio, son críticos. La radio es de valor agregado,
porque un auto sin radio igual funciona, es sólo que es más cómodo si
tiene radio. Y obviamente dependiendo de la radio y de las
características de valor agregado, sube el precio del proyecto.

No hay mucho que explicar a los “jefes” que en realidad son
"clientes". Hay que introducir test unitarios en todo y punto, así los
malos desarrolladores no pueden hacer daño al proyecto, y los buenos
se demorarán lo que se tengan que demorar.

Once upon a time, tuve un trabajo en Lan haciendo un “contabilizador”.
La idea es que había que saber los costos de transportar carga, porque
de esa manera puedes competir por precio que es la única variable que
ve un cliente (ok, tal vez también el tiempo de entrega, pero nada es
más rápido que por avión, así que se descarta esa variable)… Nuestro
equipo era el tercero que trataba de implementar la tontera, los otros
2 habían fracasado completamente. Primer mes, viene un tipo de una
empresa externa de cuyo nombre no quiero acordarme y nos explica un
caso caso de uso por día, con diagrama de secuencias.

Todos los casos de uso estaban malos. Le íbamos corrigiendo y le
decíamos qué tenía que cambiar, y yo estaba seguro que no había
diseño, tomaron los requerimientos y los pegaron en una hoja, había
cero distancia entre el requerimeiinto y el diseño y eso siempre es
una mala señal, signifca que el diseñador no hizo su trabajo y que más
encima si cambia un requerimiento, el sistema poco menso que hay que
hacerlo todo de nuevo. Más encima el sistema no cerraba.

El objetivo del sistema es que dado quete pasan una carga, la carga
puede darse 20 vueltas, ir a distintas ciudades, al cliente se le
respeta el precio acordado pero el costo peude ser compeltamente otro,
porque Lan le puede pasar un paquete a Aerolíneas Argentinas y ésta
última dejarlo en Río mientras el paquete iba a Munchen. ¿Cuánto le
tengo que pagar a Aerolíneas? Depende del contrato. ¿Y quién tiene el
contrato? Depende de la empresa que recibió el paquete, ¿pero qué pasa
si tengo un holding de líneas aéreas y hay una de las líneas aéreas
que tiene una mejor tarifa con Aerolíneas?

Imagínate eso modelado en un diagrama de secuencias. Imposible. En 10
páginas te faltaban casos que considerar, porque el diagrama de
secuencias es un corte transversal y por enderompe la encapsulación.
Eso al parecer no lo enseñan en OOP, porque se aceptan los estándares
de la industria sin cuestionamientos, pero son los proyectos
resusltantes los que sufren las consecuencias del mal diseño (si hay
un mal diseño, obviamente ninguna planficiación te lo va a arreglar, y
obviamente no puedes hacer la planificación antes del diseño, sino
¿qué estás planificando?).

¿Qué hice para que esto fuera una historia de éxito?

Esta es la parte importante, porque es contraria a todo lo que uno
aprende en la U y en las ideas que flotan en el ambiente en los
trabajos.

Hice en 5 minutos un dibujo en el pizarrón usando 3 o 4 hashmaps. Ok,
quizás fueron 5 o 6 hashmaps, pero eso fue todo. Lo expliqué y el
sistema estaba diseñado.

Explicación: Un diseño SIEMPRE es poder ver la luz al fin del túnel,
es decir, que puedas decir “ah, sí, esto lo resuelve”.

Como habáin demasiadas incognitas, esas incógnitas, que son ¿y qué se
hace en este caso? Se lleva a un Hashmap. ¿Porqué a un Hashmap?

Un Hashmap representa una computación, un cálculo, en abstracto, como
una función. Y tiene la ventaja de que no está en duro. Puedo cambair
el Hashmap en runtime, sin bajar la aplicación, puedo leerlo de una
tabla de la BD, puedo leer un Excel que representa el HashMap, etc.

Eventualmente llegó un manual tipo guía de teléfonos con todos los
flujos de cómo facturar (o pagar) a cada empresa. Leo la primera hoja
con el primer flujo y había casos que no consideraba, Por lo menos
tenía 500 páginas, o sea 500 flujos,y dada la muestra, 500 flujos
malos.

La pretensión del “cliente” o “jefe” era programar cada flujo como una
serie de “ifs”. De partida no existía el nivel de abstracción en el
código para siquiera poder escribir el código de esos “ifs”, la
abstracción estaba mucho más abajo, había que de alguna manera
categorizar la data…

O sea, fácilmente tendríamos varios años de un trabajo pérfido y sin
sentido, con un “jefe / cliente” ladrando en la oreja que cuando vamos
a terminar… En ese tipo de trabajos lo único que piensas todo el día
es “chao, idiota, arregla el problema tú sólo”. Y sabemos que en todos
los proyectos en donde hubo un programador cada 2 meses eso fue
exactamente lo que pasó.

Y la única manera de corregirlo era aferrarse al prototipo que ya
estaba funcionando. Pregunté ¿Quién escribió esta biblia? Me
presentaron a la señorita y le pedí que escribiera lo mismo en
planillas Excel, estas columnas son las entradas, estas las salidas,
escribimos el lector de planillas Excel para subirlas a HashMaps y
listo, se acabó el proyecto… Entremedio obviamente la señorita
reclamó montones, pero no era factible, ni necesario, escribir tanto
código si las planillas Excel podían contener la información.

Bueno yo creo que alguien sigue escribiendo dichas planillas.

Ah bueno y como estaba lleno de unit tests, no nos encontraron ningun
defecto, aunque sabiamos que teníamos algunos, pero esos tests lo
teníamos comentados mientras los solucionábamos. Al final del proyecto
fue como estar en permanentes vacaciones.

En resumen,si en un proyecto no hay unt tests, hay un severo problema
en la jefatura de ese proyecto. Es como tomar al bombero de la Copec y
ponerlo a dirigir una empresa multinacional o convertirlo en
presidente de la república: no tiene las habilidades, no sabe qué debe
hacer y probablemente se concentre en aspectos superficiales, como el
protocolo,el orden en que se debe saludar a los presidentes o si
cuando viene la reina de Inglaterra se le puede dirigir la palabra o
hay que esperar que ella te hable primero… si se equivoca no
importa, sólo sirve para contar anécdotas.

Es tan real esto de que los ingenieros comerciales y los industriales
no aportan valor que fíjate como fue hecho Google: Sólo aplican ideas
computinas. No tienen vendedores. No hacen publicidad. No tienen
siempre que usar el logo que representa la imagen de la compañía (por
eso tienen el doodle, para demostrar que los ingenieros comerciales
están equivocados), no partieron con un modelo de negocios
establecido, partieron con un algoritmo que funcionaba mejor para
hacer las búsquedas, etc.

Los ingenieros comerciales y lso industriales no pueden ser tus jefes
porque no saben más que tú, a menos que piensen que los ingenieros en
computación fueron a perder el tiempo a la universidad y que los otros
ingenieros sí aprendieron cosas útiles.

¿Podré ser yo jefe de ingenieros industriales? Probablemente sí, dado
lo que muestra Google. Pero lo más probable es que piense que son
idiotas porque no entienden mis ideas y los despida igual.

Las empresas más exitosas son justamente empresas formadas por
ingenieros en computación: Google, Facebook, etc. Sospecho que en
Chile estamos medio de capa caída porque no creemos en lo que
estudiamos, pero en la práctica yo creo que nuestras ideas tienen para
unos 100 años más, las implementamos nosotros o va a venir un médico o
un abogado a implementarlas MAL (porque no las entienden), no me
extrañaría que haya presidentes que sean ingenieros en computación y
le cambien la cara al país, porque si me lo preguntan, desde el punto
de vista de ingeniero en computación hay muchas cosas que se pueden
mejorar, partiendo por la economía, si al final todo es un problema de
input y output, al igual que un hashmap, no creo en los modelos
económicos imperantes, no es que proponga que haya un computador
asignando bienes y servicios en la economía, eso sería comunista, y
sabemos que los países comunistas son pobres, pero los paises
exitosos, como Suecia y todos los países escandinavos funcionan con un
modelo en que para que la economía funcione la gente tiene que ganar
dinero, si les pagas sueldos de hambre a la mitad de la población
obviamente el país nunca va a andar bien, y no importa lo que digan
los índices macroeconómicos, si la gente no ve mejorar su nivel de
vida, obviamente el sistema no esta andando bien.

Probablemente piensen que estoy drogado o se me olvidó tomar mis
medicamentos (it’s time for your medication), pero no es así, porque
les debe dar enojo, rabia, risa y hasta náuseas porque obviamente “la
economía no puede funcionar como un Hashmap”. Pero piénsalo. Las
empresas producen para satisfacer la demanda. Y la demanda es la
cantidad de gente por el sueldo promedio. De manera que el crecimiento
económico sólo se puede producir o porque aumenta la cantidad de gente
o porque sube el sueldo promedio. No hay más. Y si todos los sueldos
suben, pero no aumenta la producción eso se llama inflación.

La medida a tomar más lógica si los sueldos están bajos es disminuir
el número de horas trabajadas de 45 a 40 y aumentar las vacaciones de
3 semanas a 4. No es tan decabellado, ya que en Francia se trabaja 35
horas a la semana y tienen 2 meses de vacaciones.

Tienes que creerte el cuento, eso es lo único que puedo decir. Y por
el momento, creo que los bancos son el problema, deberiamos hacer un
banco por internet y eliminar a todos los bancos inútiles. Piensa que
cuando ahorras en el banco te dan 2% anual, y cuando usas una tarjeta
de crédito te cobran 60% ANUAL. IMAGINA si tuevieras un sitio web que
hiciera lo mismo con costo de tranasacción cero o casi cero. Se caban
los bancos de la noche a la mañana. Por cierto, así se hace la
innovación en USA: Hay que resolver un problem dificil y “quebrar
huevos”. Sin quebrar huevos no se puede hacer una tortilla.

Y no sé porque Google no lo ha hecho esto de crear un banco, pero
sospecho que Google ya cayó presa de ingenieros comerciales e
industriales, porque hace rato que no vemos innovación de parte de
Google. Eso le pasa a las empresas grandes, son demasiados los niveles
de aprobación que se necesitan para hacer cualquier cosa y todos se
sienten con derecho a “meter mano”, de modo que es el mismo efecto que
el diseño “por comité”.

Fíjense bien: IBM compra empresas y las arruina. Oracle compra
empresas y las arruina. Microsoft compra empresas y las arruina. Es la
maldición de las empresas grandes.

Las empresas exitosas parten con poca gente muy buena, resuelven un
problema dificil, crean un producto o servicio que todo el mundo
quiere. Lo vuelven escalable. BINGO. Piénsenlo un poco.


(Guillermo Schwarz) #6

En algún momento dije qu elos ingenieros en computación serán presidentes…

"La Presidenta de la República, Michelle Bachelet, comunicó a través del
Servicio Civil su decisión de nombrar a Fernando Barraza Luengo como
director nacional del Servicio de Impuestos Internos, tras elegirlo de la
cuaterna de profesionales seleccionados por concurso público realizado a
través del Sistema de Alta Dirección Pública.

La decisión fue comunicada por la Dirección Nacional del Servicio Civil al
Ministerio de Hacienda.

Fernando Barraza es ingeniero civil Industrial de la Universidad de
Santiago y posee un máster en Administración Tributaria del Instituto de
Estudios Fiscales y UNED de España. Entre 1992 y 2009 se desempeñó en
diferentes funciones en el Servicio de Impuestos Internos, siendo
subdirector de Informática del Servicio entre los años 1999 a 2009.
Actualmente, se desempeña como gerente de procesos, operaciones y
tecnología de CORFO y dirige el proyecto Escritorio Empresa de la Agenda de
Productividad, Innovación y Crecimiento del gobierno.

Por razones de buen servicio, el nuevo director del SII asumirá sus
funciones a contar de mañana."

http://www.sii.cl/pagina/actualizada/noticias/2015/110815noti01jv.htm

No estoy tan equivocado…