Embora já tenham sido identificadas boas práticas nesta área, que conseguem, de facto, reduzir o número de erros com que um software é lançado para o mercado, continua-se a ouvir por vezes que a culpa de determinado erro é o facto de o utilizador ter feito algo que não devia (como se existisse sequer esse conceito).

Independentemente da gravidade dos erros que possam aparecer, a verdade é que, por variadíssimas razões, muitas vezes o utilizador final tem uma utilização do software que não tem muito a ver com aquilo para o qual o software foi desenvolvido, explorando cenários possíveis, mas que provavelmente não foram sequer considerados como plausíveis pela equipa de desenvolvimento.

Vem esta posta a propósito do comentário que o Tiago fez sobre algum tipo de utilização do twitter:

“A mim não me dá jeito nenhum seguir blogs no Twitter! Para isso existe o RSS. Blogs no Twitter é redundante, é uma moda passageira”

Da forma que percebi o que o Tiago disse, ele está a referir-se à publicação no twitter de uma notificação que um determinado blog (normalmente o da mesma pessoa) tem um novo post.

Achei interessante essa opinião (diferente da minha) principalmente porque serviu de pretexto para pensar sobre estas questões da visibilidade online, ou seja o que queremos mostrar de nós online e como utilizar as ferramentas disponíveis para o atingir.

Para mim, todas estas ferramentas servem para mitigar uma questão muito objectiva que é o facto de oito horas do meu dia serem passadas quase exclusivamente sentado a olhar para um computador.
Com esta ocupação é evidente que o tempo disponível para contactar com pessoas directa e fisicamente é diminuto o que leva a, entre outras coisas, que seja muito difícil surgirem contextos / pretextos para o desenvolvimento de conversas.

O twitter, como eu vejo a sua utilização, é uma ferramenta que, por ser tão leve e “limitada” (cada entrada só pode ter no máximo 140 caracteres) presta-se a servir como divulgador de contextos, nomeadamente o meu contexto. E com isso refiro a tudo aquilo que me rodeia física e virtualmente.
Serve essencialmente como porta de entrada para o que faço na esfera profissional e, esporadicamente, na esfera pessoal.

E o que me rodeia é numa grande percentagem virtual, nomeadamente sites que visito, software que exploro, blog em que escrevo.
Daí que me pareça que o twitter seja um sitio ideal para, entre outras coisas, divulgar as novas entradas no meu blog, ou no delicious já que isso é uma parte fundamental daquilo que sou e que quero divulgar.
Sem dúvida que é redundante em relação ao acompanhamento individual de cada um destes sites, mas, a redundância nem sempre é má.
Até porque, neste caso concreto, sei que tenho pessoas que me acompanham no twitter que provavelmente não me acompanham via feed rss do blog.

Mas claro, quando falamos de coisas/objectos virtuais dificilmente se consegue dizer com certeza absoluta qual a sua utilização correcta.

Share/Save

Responsabilidade

• Tendo em conta que um programador / equipa de desenvolvimento não tem normalmente capacidade para influenciar decisivamente o preço, o dead-line e o tamanho da equipa que faz parte
• Só lhe pode ser pedido o máximo de qualidade no que faz
• É da responsabilidade do programador / equipa de desenvolvimento conseguir demonstrar essa qualidade.

Avaliação continua

• De que forma aquilo que faço hoje me vai garantir trabalho (aqui ou noutra empresa) amanhã?
• De que forma aquilo que faço na empresa em que estou concorre para o seu sucesso?
• Aquilo que faço na empresa é suficiente para garantir a minha visibilidade externa?
• O caminho que a empresa quer seguir é um caminho que me interessa?
• Qual o caminho da empresa / unidade de negocios em que estou envolvido?

Quais os caminhos de crescimento

• Tenho possibilidade de melhorar as minhas capacidades técnicas?
• Tenho possibilidade de melhorar os meus conhecimentos numa área funcional?
• Tenho possibilidade de fazer parte de projectos que sejam visto como inovadores pelos meus pares?
• Tenho perspectiva de carreira? Hierarquia / abrangência de funções?

Como me enquadro na empresa

• De que forma aquilo que faço na empresa em que estou concorre para o seu sucesso?
• Como é que a empresa avalia os seus colaboradores?
• Quais são os indicadores que usa para minorar a subjectividade de uma avaliação qualitativa?
• O que é que tenho que fazer para atingir os padrões minimos exigidos?
• O que é que tenho que fazer para ultrapassar esses padrões?

Share/Save

As motivações para esta decisão foram as seguintes:

• técnica – já que o Visual Fox Pro tem uma limitação em relação ao tamanho das tabelas que “só″ podem ter no máximo 2GB;
• comercial – já que o nome SQL Server é muito mais interessante que Visual Fox Pro na mente das pessoas que têm que decidir a compra de este ou aquele produto.

Considerando aquilo que se quer propor ao utilizador final, que ignora naturalmente as diferenças entre plataformas tecnológicas, este é um projecto paradoxal já que queremos vender como um produto novo, um produto que tem que ser exactamente igual ao que já existia no sentido que tem exactamente as mesmas funcionalidades.

Por outro lado a aplicação em questão que por inerência à tecnologia já é bastante performante foi ainda sendo refinada de forma a melhorar essa performance inicial, isto leva a que seja admissivel considerar que uma mudança tão substancial de plataforma tecnológica, leve a um decréscimo, mais ou menos pronunciado dessa performance. Ou seja poderá dar-se o caso do utilizador passar da versão actual para a nova versão que faz exactamente o mesmo mas mais devagar.

Outro ponto importante a ter em conta diz respeito à base inicial de trabalho no que diz respeito ao código e ao próprio ambiente e processo de desenvolvimento.�
O Visual Fox Pro é um produto bastante diferente das linguagens/plataformas da moda (.net e java), já que faz parte do mesmo ramo que o dBase e seus descendentes sendo por isso uma linguagem muito data-centric onde não faz sentido a visão que tradicionalmente nos é vendida das diferentes camadas (dados/lógica/apresentação). (Nota pessoal: não deixa de ser curioso que se trata de uma visão bem mais próxima do Progress do que de .Net)
Este paradigma data-centric permitiu opções de desenvolvimento que não são transparentes num ambiente de desenvolvimento em que temos muito claro onde estão os dados (no servidor de base de dados) e onde está o user interface (no pc do cliente).
Um exemplo muito concreto tem a ver com o preenchimento de grids. Enquanto que no Visual Fox Pro todo o processo de ir buscar os dados de uma tabela com um milhão de registo, fazer scroll up ou down, ou ir para o primeiro ou ultimo registo é bastante transparente e performante, no mundo .Net e afins este processo é mais tortuoso já que temos que aceder à base de dados, carregar tudo o que queremos e despejar no grid e assim arriscamo-nos a carregar um milhão de registos quando na verdade só queriamos meia dúzia com todo o custo de performace associado ou então a ter que implementar estratégias de paging que sendo possiveis e exequiveis representam mais linhas de código e fatalmente maior probabilidade de erros.
Claro que podemos simplesmente questionar qual o interesse efectivo de um grid com um milhão de registos mas isso implica conseguir mudar a forma como os programadores inicialmente desenvolveram a aplicação e os utilizadores que estão habituados a um determinado interface.

Finalmente sendo uma aplicação já com alguns anos e sem nenhuns testes formais desenvolvidos, e aqui estou a pensar em testes unitários, a probabilidade de cairmos em situações em que por mexer num pedaço de código estamos a afectar outro pedaço de código de que não temos noção é muito grande.

Claro que todas estas notas são simples alertas para questões que outras pessoas já sentiram e não são por si só justificativas da opção de seguir com o projecto ou de abandoná-lo.
Para chegarmos a essa conclusão temos que antes conseguir responder a outras questões:

• o problema técnico que leva a esta decisão não consegue ser resolvido de outra forma?
• qual o cenário previsivel de vendas desta nova versão? ou seja em quantas vendas prevemos diluir este custo em que estamos a incorrer?
• é aceitável algum nivel de degradação de performance? se sim que quantificação objectiva podemos definir?
• qual o âmbito real do projecto? todos os dados têm que ser guardados ou em SQL Server ou em Visual Fox Pro ou podemos ter as duas tecnologias ao mesmo tempo, por outras palavras podemos ter produtos intermédios totalmente funcionais?
• qual a duração previsivel de vida deste produto? até onde temos que considerar questões de manutenção futura e por isso até onde devemos considerar importante o desenvolvimento de mecanismos que nos permitam melhorar no futuro o tipo e rapidez de resposta nestas manutenções?

Só depois destas resposta terem sido dadas e na certeza de que certamente que nenhuma delas é uma resposta absoluta e definitiva (grow software vs build software) é que podemos chegar a uma conclusão mais confortável já que assente em alguns pressupostos.

Share/Save

“Notice in particular the differences between a team of two programmers conventionaly organized and the surgeon-copilot team. First, in the conventional team the partners divide the work, and each is responsible for design and implementation of part of the work. In the surgical team, the surgeon and copilot are each cognizant of all the design and all of the code.”

seja na definição do âmbito da nossa profissão, da matéria com a qual trabalhamos e do que nos leva a gosta de trabalhar nela.

“capitulo 2 – The Mythical Man Month pag. 15
The programmer builds from pure thought-stuff: concepts and very flexible representation thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified.”

É dificil sintetizar todo o livro numa palavra, mas sendo um livro mais ou menos de gestão de projectos, é também um livro de gestão de relações humanas e de constatação que o desenvolvimento de software mais do que um fim (o produto final) é um processo – “grow, not build, software”.
Apesar de estarmos cada vez mais acima nas camadas de abstracção que nos levam do hardware (porque todo o software ainda corre num hardware) até ao domínio de negócio que queremos “softwarizar” continua a ser verdade que:

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other sofware systems. No other part of the work so cripples the resulting system if done wrong. No other part is so more difficult to rectify later.
Therefore the most important function that software builders do for their clients is ther iteractive extraction and refinement of the product requirements. For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and they almost never have thought of the problem in the detail that must be specified. Even the simple answer – “Make the new software system work like our old manual information-processing system” – is in fact too simple. Clients never want exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software activity, it is necessary to allow for an extensive iteraction between the client and the designer as part of the system definition.
I would go a step further and assert that it is really impossible for clients, event those working with software engineers, to specifiy completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.”

Torna-se por isso para mim cada vez mais claro que um projecto de desenvolvimento de software é um projecto onde não se consegue especificar concretamente o que vai ser feito e logo quanto tempo vai demorar a fazer e portanto quanto é que deve custar.

“The programmer delivers satisfaction of a user need rather than any tangible product” (pag.241)

E com uma definição tão abstracta para algo que no fim vai ser muito concreto (n linhas de código) percebemos que um projecto que tem que assentar na confiança entre todos os participantes do projecto.
Note-se no entanto que esta confiança não tem a ver com a ideia de fé ou crença mas sim de confiança porque todos os dados disponiveis apontam para que as soluções optadas são as mais apropriadas. Certamente que haverá erros durante o processo mas estando todos os envolvidos no projecto a par das decisões e dos objectivos, esses erros não terão mais relevância do que a necessária para evitar que se repitam.

Para além da ideia de desenvolvimento incremental e da ideia clara que “the clients do not know what they want”, outro ponto importante que é referido tem a ver com o papel do gestor de projecto e a sua relação com as pessoas que está a coordenar.
Como acontece provavelmente em relação a todas as profissões, também no desenvolvimento de software, a definição de prazos e datas é uma espécie de luta entre quem define o tempo que as tarefas demoram (programador) e quem quer gerir os deadlines (gestor de projecto) como se o facto de se querer algo mais rápido fosse sinónimo de ser possivel ter algo mais rápido…

“The project manager has to keep his fingers off the estimated dates, and put the emphasis on getting accurate, unbiased estimates rather than palatable optimistic estimates of self-protective conservative ones.”

Ou seja, em vez de números e datas à partida irrealistas mas com potencial “psicológico” para o nivel hierarquicamente superior e/ou clientes, é preferivel batalhar para ter datas fiáveis e por isso cada vez mais confiáveis.

Todos estes pontos parecem às vezes banalidades e/ou generalidades com que todos podemos concordar, mas como disse no inicio não é pelo facto de eu os conhecer que não sofri até agora na pele o efeito de cada um desses pontos…

• notas leitura: The Mythical Man-Month 1
• notas leitura: The Mythical Man-Month 2
• notas leitura: The Mythical Man-Month 3

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

Frederick P. Brooks

Share/Save

pag. 156
“But every boss needs two kinds of information, exceptions to plan that require action and a status picture for education. For that purpose he needs to know the status of all his teams. Getting a true picture of that status is hard.”

pag.158
“The project manager has to keep his fingers off the estimated dates, and put the emphasis on getting accurate, unbiased estimates rather than palatable optimistic estimates of self-protective conservative ones.”

capítulo 15 – the other face
pag. 165
“Different levels of documentation are required for the casual user of a program, for the user who must depend upon a program, and for the user who must adapt a program for changes in circumstance or purpose.”

“To believe a program. The description of how it is used must be supplemented with some description of how one knows it is running. This means test cases.”
pag. 166
“1. Mailine cases that test the program’s chief functions for commonly encountered data.
2. Barely legitimate cases that probe the edge of the input data domain, ensuring that largest possible values, smallest possible values, and all kinds of valid exceptions work.
3. Barely illegitimate cases that probe the domain boundary from the other side, ensuring that invalid inputs raise proper diagnostic messages.”

capitulo 16 – No Silver Bullet – Essence and Accident in Software Engineering
pag. 199
“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other sofware systems. No other part of the work so cripples the resulting system if done wrong. No other part is so more difficult to rectify later.
Therefore the most important function that software builders do for their clients is ther iteractive extraction and refinement of the product requirements. For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and the almos never have thought of the problem in the detail that must be specified. Even the simple answer – “Make the new software system work like our old manual information-processing system” – is in fact too simple. Clients never want exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software activity, it is necessary to allow for an extensive iteraction between the client and the designer as part of the system definition.
I would go a step further and assert that it is really impossible for clients, event those working with software engineers, to specifiy completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.”

pag.200
“Incremental development – grow, not build, software”

pag.241
“The programmer delivers satisfaction of a user need rather than any tangible product”

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

Frederick P. Brooks

Share/Save