Monthly Archive for janeiro de 2009

Delphi - Verificando se o TDataset esta vazio

Jefferson que trabalha comigo, me questionou o que era mais rápido para verificar se havia dados em um TDataset, verificar a propriedade RecordCount ou a propriedade Eof?

var
  Q: TQuery;
begin
  …
  Q.Open;
  if not Q.Eof then
    …
  // ou
  if Q.RecordCount > 0 then
    …
 

Fiquei sem saber a resposta e falei para ele testar. Ele chegou a conclusão que o método Eof era instantâneo ao contrário do RecordCount.

Acredito que internamente a propriedade RecordCount deva “levantar” a quantidade de registros no momento em que ela é lida. Pelo menos no BDE que foi o tipo de comunicação que foi utilizado nos testes.

Independente disso, no TDataset existe uma propriedade que é mais legível, a IsEmpty:

var
  Q: TQuery;
begin
  …
  Q.Open;
  if not Q.IsEmpty then
    …
 

Pensando um pouco com relação as subestimativas

Recentemente, andei pensando na questão das subestimativas de esforço com relação aos desenvolvimentos de software. Mesmo sem nenhuma estatística é fácil dizer que a grande maioria das estimativas de esforço e tempo para desenvolvimento e implantação de softwares são menores que os reais.

Percebi nos meus tempos coordenando que os mais “novos” (de experiência) subestimam mais que os mais “velhos”.

Filosofando um pouco, acabei chegando a 2 conclusões.

Pessoas não “contam” a parte ruim

Não sou psicólogo, mas acredito que as pessoas no momento inicial da estimativa, apenas “lembram” das partes prazerosas do seu trabalho, as partes penosas são subtraídas deste pensamento, isso faz com que ele vê menos esforço com relação ao real. Acredito que os mais experientes acabam lembrando do não prazero por terem “apanhado” muito no passado.

Uma forma de evitar este equivoco seria criar um diário de bordo com anotações com todas as tarefas exercidas pelo profissional. Quando for estimar uma nova atividade, este ”olharia o passado” para verificar quais são as atividades (tanto as prazerosas, quanto as não prazerosas).

Estimativas de valor alto são penalizadas 

Pelo menos em empresas de desenvolvimento pequenas, sempre que alguém estima um prazo grande para uma atividade, levanta-se a discução, as vezes em vários níveis da empresa, se aquela informação esta correta. Já escutei um vendedor questionando que com aquele esforço ele não conseguiria vender (dado que o valor cobrado do cliente era proporcional ao esforço passado). Para o desenvolvedor, que só quer desenvolver, estes questionamentos funcionam como uma espécie de castigo e quando ele subestima, ninguém reclama.

É comum vermos reclamações quanto a não entrega em data pré combinada a reclamações quanto a subestimativa. Tem a ver com a memória curta das pessoas. Acredito que neste caso o desenvolvedor não sinta culpado pela subestimativa e portanto o fato de não ver problema nela. Os mais experientes acabam aprendendo a dura lição e acabam criando opniões fortes que combatam os questionamentos, o efeito colateral é que estes acabam tornando-se intransigentes.

Quanto esta segunda conclusão, acredito que para resolver deveriamos repensar as broncas, a estimativa deve ser comparada com o realizado, e apenas neste caso um desvio deve ser questionado (tanto para cima quanto para baixo). O questinamento prévio deveria ser evitado a todo custo.

E você o que pensa disso?

De sua opnião nos comentários, me diga porque acha que exista a subestimava e como devemos tratar para resolver.