I’ve just stumbled on this post by Danilo Sato and remembered what a great time we had on the Kake Coding Dojo last August, at Agile 2009.

Want to know what a Kake Coding Dojo is? Hugo Corbucci explains it on his blog, and so does Danilo (note that this Coding Dojo format was previously called UberDojo).

I’m tempted to promote some Kake sessions with fellow co-workers. We’ve been talking about ways to share knowledge on TDD and other agile practices across the company, and I found this to be an excellent way to improve one’s TDD skills, and to have contact with different languages while we’re at it. Will try to report back on my findings.

Update: Hugo has just made a post about this too, with some extra info.

The fellow who designed it, is working far away;
The spec’s not been updated for many a live-long day.
The guy who implemented it, is promoted up the line;
And some of the enhancements didn’t match to the design.
They haven’t kept the flowcharts, the manual is a mess;
And most of what you need to know, you’ll simply have to guess.

by David Diamond

Update: This is dated June 1976, by the way.

Uma leitura interessante, o último artigo do Paul Graham (como muitos dos artigos dele o são), no qual reflecte sobre os efeitos de trabalhar numa empresa grande, ou numa empresa pequena.

Muitas destas ideias vão muito ao entro à minha opinião sobre estes assuntos, e têm tudo a ver com agilidade.

The restrictiveness of big company jobs is particularly hard on programmers, because the essence of programming is to build new things. Sales people make much the same pitches every day; support people answer much the same questions; but once you’ve written a piece of code you don’t need to write it again. So a programmer working as programmers are meant to is always making new things. And when you’re part of an organization whose structure gives each person freedom in inverse proportion to the size of the tree, you’re going to face resistance when you do something new.

There is one thing companies can do short of structuring themselves as sponges: they can stay small. If I’m right, then it really pays to keep a company as small as it can be at every stage. Particularly a technology company. Which means it’s doubly important to hire the best people. Mediocre hires hurt you twice: they get less done, but they also make you big, because you need more of them to solve a given problem.

E assim terminou o DSIE’08, após algum stresse, após o já tradicional nervosismo de falar perante audiências, e após um ou outro percalço organizativo, o saldo final é bastante positivo. Surgiram artigos bastante variados, tanto em termos de tema, como em termos de nível de progressão na investigação.

Fica a experiência adquirida e algumas recordações. Para o ano haverá mais, pelas mãos de outro pessoal.

Ao ler sobre sobre o padrão de análise Accountability, do Martin Fowler, dei com esta pérola de descrição:

If you are dealing with an organization with a single hierarchy, or even a couple, then Organization Hierarchy is the simplest way to deal with things. However larger organizations grow beyond this. You often find a host of different relationships between parties, all of which carry their own meaning. If your hierarchies start breeding like viagra infused rabbits, it’s time to look to Accountability.

Até Fevereiro do próximo ano participo na organização de um simpósio/mini-conferência, o DSIE — Doctoral Symposium on Informatics Engineering. Será uma reunião de investigadores em várias áreas da engenharia informática, na sua maioria do ProDEI da FEUP, que se reúnem para dar a conhecer o trabalho uns dos outros, e receber feedback em relação a esse trabalho.

Foi hoje lançada a respectiva chamada à submissão, quem pretender participar com o envio de artigos, tem já disponível a interface para o efeito. Quem pretender participar como espectador terá de esperar mais uns dias para se registar (os registos serão gratuitos, a propósito).

Actualizado: Alguém interessado em ser patrocinador? Por favor estejam à vontade para me contactar nesse sentido… :)

Vai brevemente ter lugar na FEUP um curso de Desenvolvimento Ágil de Software (28 horas lectivas). Do que conheço dos formadores e do tema, recomendo em absoluto!

Ontem assisti na FEUP a uma apresentação muito interessante com o tema Adaptive Object Models (AOM), feita pela autoridade neste assunto, Joseph Yoder. Cinco estrelas.

Publicaram o Plano de Educação Contínua da FEUP até Novembro de 2007. Sendo as mais interessantes, da minha perspectiva:

• Test-Driven Development – de 22 a 24 de Março
• Agile Project Management – de 23 a 25 de Maio
• Desenvolvimento Ágil de Software – em 14, 15, 21 e 22 de Junho
• Building Service Oriented Architecture – concepts, patterns and technologies – de 25 a 28 de Junho

Excerto do livro eXtreme Programming Explained, do Kent Beck, sobre as quatro principais variáveis de controlo num projecto:

Cost — More money can grease the skids a little, but too much money too soon creates more problems than it solves. On the other hand, give a project too little money and it won’t be able to solve the customer’s business problem.


Time — More time to deliver can improve quality and increase scope. Since feedback from systems in production is vastly higher quality than any other kind of feedback, giving a project too much time will hurt it. Give a project too little time and quality suffers, with scope, time, and cost not far behind.


Quality — Quality is terrible as a control variable. You can make very short-term gains (days or weeks) by deliberately sacrificing quality, but the cost—human, business, and technical—is enormous.


Scope — Less scope makes it possible to deliver better quality (as long as the customer’s business problem is still solved). It also lets you deliver sooner or cheaper.


There is not a simple relationship between the four variables. For example, you can’t just get software faster by spending more money. As the saying goes, “Nine women cannot make a baby in one month.” (And contrary to what I’ve heard from some managers, eighteen women still can’t make a baby in one month.)

Eu diria que é nada mais que senso comum, mas quando dito de uma forma tão simples e clara aproxima-se de genial!