Gastón Ramos

"La mayoría de las gaviotas no se molesta en aprender sino las normas de vuelo más elementales: como ir y volver entre playa y comida. Para la mayoría de las gaviotas, no es volar lo que importa, sino comer. Para esta gaviota, sin embargo, no era comer lo que le importaba, sino volar. Más que nada en el mundo, Juan Salvador Gaviota amaba volar".

Category: xp

47

En un proyecto en el que estoy trabajando se me ocurrió saber cuantos devs habían pasado por ahí, es decir cuantas personas diferentes modificaron el código, como no sé cual es comando de git que le corresponde lo resolví en bash:

git log | grep Author: | sort -u | cut –delimiter=” ” -f2 | sort -u | wc -l

Por supuesto que el cálculo no es exacto pero en menos de 1 minuto obtuve una respuesta bastante cercana a la realidad:

47

¿Lindo número para jugar en quiniela eh?

PD: Gente, Lead Projects, Developers, CTOs, Etc. Hay que tratar de mantener ese número lo más bajo posible, en mi opinión más de 4 es mucho, así que para este caso estoy en un orden 10x de lo que es aceptable para mí :).

PD: Que bueno hubiese sido que de 5 números menos :D

¿Qué opininan?

How Do You Plan Infrastructure?

Sigo con la lectura del libro de Kent Y Martin, ahora quiero compartir on Uds. una parte del capítulo 10 titulada “How Do You Plan Infrastructure?”:

“When you plan in a function-oriented, such as we suggest, the obvious question is how to deal with infrasctuture. Before we can start building functionality we have to put together the distributed object messaging infranstructure components before you deliver any customer functionality.

This style of development is a common feature of the dead and dying projects we’ve seen-and we don’t think it’s a coincidence. Doing infrastructure without customer function leads to following risks:

  • You spend a lot of time no delivering things that are valuable to the customer, wich straints the relationship with with customer.
  • You try to make the infrastructure cover everything you think you might need, wich leads to an overly complex infrastructure.

Therefore, evolve the infrastructure as you build the functionality. For each iteration, build just enough infrastructure for the stories in that iteration. You won’t build a more complex infrastructure than you need, and the customer is engaged in building the infrastructure because she sees the dependent functionality as it’s evolving.”

Creo no hace falta agregar nada, sólo que estoy totalmente de acuerdo con lo que dice.

Overtime doesn’t help.

Hace poco comencé a leer el libro “Planning Extreme Programming” de Kent Beck y Martin Fowler (dos grosos) leyendo el capítulo 7 hay un párrafo que me gustó mucho y quería compartirlo, paso a detallar:

“Overtime doesn’t help. Although in the very short term it does speed up the team, if you do it for any length of time you will get bitten badly. The big killer is motivation. It’s much better to have a motivated programmer work seven hours than a tired, distracted programmer work ten. Even if the programmers want to work long hours it’s not a good idea. Long hours make people tired, tired people make mistakes, and mistakes take time to fix. We’ve both gone into clients in the morning and spent all day chasing a bug that was put in a ten o’clock the previous night. Particularly with young Silicon Valley teams, where long hours are such an important tribal ritual,  we have to work hard to get people not to do overtime. If they really have no life, get them to play computer games in the evening instead. It’s much more productive to have castles mown by trebuchets than it is to slip bugs into complicated software.”

La verdad me encantó esta parte del capítulo, sobre todo por que en este último tiempo me he econtrado con varias personas que valoran el “overtime”  por más que ello no favorezca a que el sistema avance, y en lo personal trato de no trabajar fuera de hora o cuando estoy muy cansado.