Kent Beck diz: "No Tests?"

Ok, melhor explicar isso:
Kent Beck sugere a abolição de testes para pequenos projetos.

Discussão sobre isso por Mark Levison, aqui.

Testes são como muitas coisas em software, uma questão de julgamento ("sensibilidade"?).

Nesse quesito, concordo com número, gênero e grau com Kent.

Se você está numa fase exploratória... simplesmente tentando novas ideias para ver se pode se comprometer com
essa ou aquela abordagem, por que usar TDD, por exemplo?

Agora, se você é muito apegado ao design e fazendo um trabalho exploratório, e você prefere TDD - então use-o! Use o melhor de seu julgamento para fazer a decisão baseada na sua situação atual.

Em tempo: não sou um "expert" em TDD, até comprei o livro que achei certo, mas tenho feito poucas coisas.

Para mim, prefiro ser pragmático, NÃO dogmático. Eu prefiro usar meu cérebro para fazer o que faz mais sentido em todas as circunstâncias, não é uma cega fidelidade a um modelo de processo para processo. Se fazendo "concepção e codificação" funciona melhor para você e sua equipe para dar consistência às ideias, vá em frente. Só não se esqueça de voltar atrás e "fazer as coisas certas", uma vez que você vai se comprometer a uma abordagem que vai ficar no código.

Diversity of opinions on JDK 7

JDK 7 is the next major Java release. In this post over at the editor's blog at java.net, a recent poll reveals the perception among some in the Java community with respect to this release. The voting on the question 'What's your view of the emerging JDK 7?' revealed the following:

* 10.4% (51 votes) - It's a major step forward
* 30.3% (148 votes) - It includes some important features
* 16.3% (80 votes) - It's a typical JDK release
* 41.5% (203 votes) - The most significant problems are not addressed
* 1.2% (6 votes) - Other

Beside this vote, the poll also gathered more open ended responses in regards to JDK 7 which also show a wide diversity of opinions on this release.

Read the entire post entitled 'Poll Reveals Diversity of Opinions on JDK 7', here.

Métricas

E eu tenho esses pensamentos sobre métricas...

O desafio que eu vejo não é tanto sobre como recolher métricas no desenvolvimento de software. Vários anos usei métricas (quem lembra do famoso ciclomático?) quando trabalhava em sistemas de missão crítica e sempre tentei deixar o meu código e modelos de implementação tão bom quanto possível, sem ser muito louco por tudo.

O que é um bom nível de métrica? Sim, isso todos nós sabemos, "Você não pode melhorar o que você não mede."

Mas o que estamos tentando melhorar? Qualidade? Confiabilidade? Agilidade para fazer alterações? Lucro?

O que fazer para correlacionar uma medição a um resultado desejado? Podemos vincular um conjunto de métricas e o seu impacto sobre as metas comerciais para o software? Menos complexidade igual a mais lucro e mais (felizes) clientes?

Ou vamos parar logo para que "sensibilidade" (métricas) atinjam "qualidade" e, presumo que se medirmos uma determinada aplicação para satisfazer o "direito" no nível de qualidade, o valor comercial irá naturalmente seguir?

Este é um dilema difícil para a nossa indústria. Mas temos que começar por algum lado.

No mundo da engenharia, existem medidas que podem ser vinculados ao desempenho desejado e custo. Precisamos de algo semelhante que queremos ver maduro, e não apenas saias-justas, desculpas e "sensibilidade" técnicas; muito menos aves de mau agouro (embora acho essas aves úteis).

Estou certo que algumas pessoas têm isso como uma ciência ... e para eles, deve ser uma bela vantagem competitiva que é provavelmente difícil para partilhar publicamente.