Requirements Engineering - No man's land

Software engineers have to conquer the problem space but they would happily be away of it.

Software engineers love solutions. They like to play with several ways to solve a problem, compare them, discuss the advantages and disadvantages of each one of them, and explain the trade-offs and compromises taken to reach a particular solution. They feel comfortable in the solution space.

Curiously you can also play in the problem space. It is possible to write nice descriptions of the problem, compare them, and discuss their advantages and disadvantages. However, software engineers do not feel comfortable because it can become a never ending game, a kind of language trap. The description of the problem becomes an end in itself.

The best way to understand a problem is to write a solution to it, but, unfortunately this is not always that simple. It is true that complex problems can be solved by simply writing a solution to them. For instance, the solution for the logic puzzle, When is Cheryl's Birthday? by Peter Norvig is done describing the problem in terms of logic and letting the computer process the answer. These are logical problems but a group of other software engineering problems contain a lot of business logic which people very often argue to be illogical. Business logic is characterized by the lack of a elegant model which synthesizes the main aspects of the business. Actually, it results from the compromise between conflicting requirements from different stakeholders. It contains a large number of rules, each rule has many variations and exceptions which emerge because of the need to combine different situations. For instance, suppose that in a banking application credit card holders receive points whenever they use their credit card. This simple rule can have a lot of variations. The number of points received depends on the type of client, amount expended, the used currency, past use of the card, the period of the year, a marketing campaign, etc. Business logic diverge from nicely formulated logical problems because the complexity is on the number of rules and their variations, and the possibility that some of the rules may be inconsistent, and so the challenge is on how to manage this complexity of size. It is necessary to write a lot of lines of code to solve the problem whereas in the logic puzzle the solution is elegantly written with a few.

Software engineers have to write a description of the problem that has a similar complexity, in terms of size, than the final software artefact. The description needs to be complete, it captures all requirements, and consistent, there are no conflicting requirements, which means that it is necessary to validate the description to guarantee that it satisfies the users's needs. Therefore, the efforts necessary to create problem descriptions is similar to the one necessary to create the solutions. Additionally, it is necessary to maintain the traceability between the problem and solution descriptions to support changes in the requirements and the resulting evolution of the system.

Since software engineers have to repeat their activities in the problem and solution descriptions it raises the question why do we write a problem description? Wouldn't it be possible to focus on the writing of the solution?

There several approaches to this question.

The first approach is that it is necessary to communicate with the stakeholders and natural language needs to be used. Therefore, the next step is to write the result of this communication in a document, the user requirements definition. From this natural language description you can create a more detailed document, a system requirements specification, which can be used to communicate with the development team. This approach follows the strategy of having several small transformations between description in the software development process.

Agile approaches try to avoid the use of written documentation. Actually, it is possible to have descriptions of the problem but they serve as an auxiliary artefact for the communication, they do not substitute the communication. Therefore, it does not need to be maintained nor managed. For instance a list of stories is used as a requirement documents, but each story is only a entry point for a conversation (interaction) between the client and the development team. It is not expected that just by reading the story the team will be able to implement it. Using these approaches software engineers play with code and do not need to repeat the same activities in different artefacts, e.g. validation of the requirements and validation of the final system.

Model-driven engineering approaches intend to use executable models that are closer to the problem space and use code generation techniques to produce the final software artefact. Therefore, software engineers will interact with the client at a level of abstraction that is closer to the problem space. By following these approaches software engineers do not repeat activities because the semantics of the model and the correct implementation of the code generators ensures that the final system will have the same properties that were verified in the model. The agile modeling approach was the first intent to integrate modeling and the agile paradigm.

In Software Engineering Companion

What is Software Engineering

It's completed, the first draft of the painting!

What is Software Engineering?

Software as Art and Engineering

A recurring question, Is Software Art?, for the Software Engineering Companion

Software Engineering Companion: What is Software Engineering?

Although not finished yet, some contributions to the topic:

• Definitions of software engineering
• Software Development as a Formalisation Process
• The Scope of Software Engineering

Comments and suggestion welcome!

Software Engineering Companion

I've decided to start writing a Software Engineering Companion using the MediaWiki software.

In Why do we need a companion? I argue that in the discipline of Software Engineering, more than a book, we need a companion.

I'll keep posting as the different sections are being written!

Exceptions as gotos

try

{

    Client client = getClientByName(name);

    throw new ExistsClientNameException(name);

}

catch (DoesNotExistClientNameException e)

{

    addClient(new Client(name));

}

Interesting times

Yesterday evening, while chatting with a colleague over dinner, he mentioned this sentence by someone, whose name I cannot recall now: may you live in interesting times. 

Definitely, we live in interesting times. We cannot have a logical, and meaningful, grasp of the future. Of course, we can look at the past and try to foresee the future, but, though the future will for sure repeat something that already happened in the past, we have no idea about what it will be. These times are interesting and risky. 

During the DESRIST conference, there were discussions about innovation and design, and it occurred to me that there is some kind of paradox between design and innovation. For instance, when we design the software architecture for a system, first, we try to build a common understanding among all stakeholders on what is the problem and what are the requirements for the solution. Then, the architect designs an "elegant" solution that fulfills the stakeholders needs and, hopefully, he expects to come out with something that contains some innovation. However, if the result is innovative most of the stakeholders would have disagreed beforehand with it. When there is innovation, consensus is a result of innovation and not its source.

Life is not by design and we live in interesting times.

Science and Enginering

This week I presented an article at the DESRIST Conference in Las Vegas on the integration of IT and organizational design. This conference is the forum for Design Science research, which focus on the IT artefact and its process of construction. This community has its conceptual roots on Herbert Simon's work on the Sciences of the Artificial (1969).

I'm writing this post because I was struck by two different issues, a recurring discussion and an elegant formulation.

First the recurring discussion. During the two conference panels, it was referred the resistance of the academia to accept research on design. Fifteen years ago I remember being involved in similar debates in the context of the design patterns community. The design patterns community had a huge impact on software engineering. Today software developers use design pattern jargon to communicate their designs, the design patterns knowledge is part of the experts language. However, the design patterns community impact on academia is small and its publication outlets, the PLOPs conferences, are not the best forums to publish if you aim to get a PhD degree. Why this happen? An interesting article by Davenport and Markus (Rigor vs. Relevance Revisited: Response to Banbasat and Zmud, 1999) make it clear. Academia pursuit rigor (science) but has some difficult in accepting relevance (engineering) because of its "lack of rigor". Designing and building a system is a clumsy task which is difficult to assess. However, Davenport and Markus argue that the academia must find the means to reward the research on best practices. How? Well, the recurring discussions show that this is not an easy task.

On the elegant formulation, I was positively surprised by Alan R. Hevner formulation of design science research which integrates relevance and rigor in three feedback cycles (A Three Cycle View of Design Science Research, 2007).

Design Science Research Cycles (Hevner, 2007)

From a software engineering perspective, Hevner formulation covers from empirical software engineering, in the relevance cycle, to fundamentals of programming languages, in the rigor cycle. Besides, it gives design science a central role on bridging the gap between rigor an relevance.

I would not say that this perspective is the ultimate solution for the recurring discussions, but it provides  the lens through which we can view software engineering research, and design research in general.

A história universal dos impostos

A história da humanidade poderia ser escrita em função da história dos impostos. Impostos em sentido lato, ou seja, a forma como cada indivíduo, quer seja de livre vontade, quer seja coagido, contribui com parte dos seus recursos materiais para o bem comum. Desde o tempo da escravatura e do Robin dos Bosques até aos dias hoje o processo das contribuições individuais e da sua redistribuição pela comunidade tem procurado ser cada vez mais transparente e equitativo.

A atual crise democrática está ligada a um desfasamento, pelo menos ao nível da perceção de cada indivíduo, entre o que contribui para a comunidade e o que recebe em troca. E o que recebe em troca não necessita de ser de forma direta, pode ser através de estabilidade e diversidade social que podem ser a fonte da geração de mais riqueza. O nível de educação de uma comunidade ou o cultivar da diversidade de opiniões dentro da comunidade são disso exemplos.

Em torno deste desfasamento geram-se duas interpretações ligadas quer à direita quer à esquerda. Segundo a direita existe um esbanjamento dos recursos que são redistribuídos, quer porque a máquina de redistribuição é ineficiente, quer porque os beneficiários da redistribuição não a merecem e acomodam-se. Já a esquerda é muito cautelosa em colocar em causa a máquina de redistribuição e enfatiza a importância social da redistribuição, mas encontra-se atualmente na mó de baixo do senso comum sobre este problema.

Contudo, o processo de redistribuição é mais complexo e a ineficiência não está apenas ligada ao funcionamento da máquina mas também à decisão. Ou seja, a decisão de como e onde se gastam os recursos partilhados está longe das pessoas. E esses valores não são desprezáveis. São valores muito significativos que fazem mover uma parte significativa da economia. Por exemplo, a guerra no Iraque foi paga com o dinheiro dos impostos dos Norte-Americanos e houve muitas empresas privadas envolvidas, quer diretamente na utilização desse dinheiro, quer indiretamente nos negócios gerados em consequência da guerra. Este aspeto da ineficiência da distribuição não é muito referido pela direita e provavelmente origina um maior esbanjamento do que o da ineficiência da máquina do estado. Mas, como disse, não é esse hoje em dia o senso comum.

Considera-se que a invenção da imprensa marca o fim da idade média e o início do período moderno. O seu impacto foi enorme. O acesso e a divulgação do conhecimento ficou mais fácil, aumentou a diversidade, deixou de ser necessário pertencer a uma classe social, o Clero, para ter acesso ao conhecimento, e teve até influência no sucesso da cisão religiosa de Lutero e Calvino pela facilidade e relativo baixo custo com que as traduções da bíblia puderam ser divulgadas. Não obstante o seu impacto, a invenção de Gutemberg resultou da adequada combinação de um conjunto de técnicas conhecidas na altura. Um exemplo da construção de um produto de engenharia.

Também para os impostos é necessário um produto de engenharia. Este produto caracteriza-se por separar a decisão sobre quais são os objetivos da comunidade da forma como eles são concretizados. Os primeiros são definidos conjuntamente pela comunidade quando elege os seus governantes, já os segundos devem ser concretizados por cada indivíduo de acordo com o contributo que a comunidade decidiu lhe atribuir. Os governos definem os objetivos sociais e as pessoas gerem a aplicação da sua contribuição. Os governos são avaliados pelos objetivos sociais que definem, as pessoas são avaliadas pelo sucesso com que gerem a sua contribuição.

Sobre este mecanismo esbocei algumas ideias num post sobre a Gestão dos Impostos, mas agora interessa perceber da viabilidade desta solução. Sim, porque facilmente se alegará que é impossível. Esse argumento terá provavelmente duas facetas, uma técnica e outra social.

A impossibilidade técnica versará sobre a complexidade do problema. Sobre ser impossível medir o sucesso de como as pessoas gerem a sua contribuição. Sobre não ser possível tratar toda a informação ou categorizá-la. Creio que tal como a invenção da imprensa, também aqui as técnicas já existem hoje em dia, é apenas necessária combiná-las de forma adequada.

Já a impossibilidade social é mais subtil, pois está ligada ao poder. Mas o principal argumento terá a ver com as pessoas poderem não ser capazes de tomar as decisões certas. Também aí, o exemplo da imprensa de Gutenberg pode ajudar, pois muito provavelmente um dos argumentos contra a tradução da bíblia seria a sua má interpretação pelos leigos. Mas a história encarregou-se de mostrar precisamente o contrário.

Social Mirror - Some Challenges

In a previous post I stated that the SocialMirror should be a software application that allow people to steer their own public image, and ensure some fairness among all concerned. Now, it is necessary to detail the application goals and features. To keep focus on the relevant issues, I start to identify the challenges SocialMirror has to face, and to do so I'll follow different strategies.

In this post I analyse some software applications and games where the concept of social mirror is built-in. By identifying similarities and differences between them and SocialMirror, I aim to raise some questions which will help me in the design of the solution. On the other hand, these questions will help me stick to what is important.

I have chosen one software applications and two games, actually, one of the games is also a software application.

Facebook is the largest social network in the world. It is mainly used for socialising, though the number of satellite applications which intend to take advantage of the large users base is increasing. By and large, Facebook allows people to interact in a number of ways, but socialisation around content has become viral. Contents, such as pictures, videos, and news, trigger endless interactions, eventually stopped by fresh contents that drag people to another context. However, because socialisation is a confirmation process, are you there?, do you still feel the same?, are you the same?, people move but they keep on socialising. The relation to social mirrors is obvious. In the tender mirrors post I exploit a found-art technique, I anonymised a thread where teenagers where commenting a picture and I did some random reshuffling as well, to illustrate how in Facebook self-awareness comes out from among others mirrors. Therefore, SocialMirror should also take advantage of contents to trigger interaction, but it should avoid that people easily converge for the sake of its fairness quality.

Truth or Dare is a game where the players have to choose between answering to a question or performing a task, both usually embarrassing. Similarly to the Facebook case, by answering others questions or performing tasks they propose, a public image is being built. However, contrarily to Facebook, in the Truth and Dare game is not so easy to converge because, due to the game rules, tasks and questions should be embarrassing. SocialMirror may follow some the the Truth and Dare rules to achieve some fairness, though it is not clear how to bring players to the game if they are not willing to.

FearNot! is a very interesting application that uses role-playing to create emotional self-awareness on bullying situations. It provides the player with a set of scenarios where he advices a victime of bullying. By doing so, the player becomes affectively engaged and create the right behaviour that will help him as either a victime or a bully. FearNot! addresses the Truth and Dare open question, how can we engage people in SocialMirror? In this case, people are engaged in the game by accepting to do a good deed. However, the context is pre-defined and form a closed world. For instance, FearNot! ignores that the bullies are also interacting to create their own public image, and very often the victime works as a catalyst. SocialMirror should have a wider scope,  it should support an open world closer to Facebook.

Social Mirror - The Context

According to the social mirror theory, people's self-awareness depends on how they see themselves through others's eyes: "we cannot have mirrors in the mind unless there are mirrors in society". Therefore, self-awareness is a social construction where everyone is committed.

The article, although short, is not easy to read. Nevertheless, I would suggest you to give it a try. It is inline with some of the ideas on social construction I have been discussing on both this blob and curtas. I am particularly fond of the role-play mechanism in the mirrors construction. The author goes a little bit further and argue that it is role-playing which distinguishes humans from other animals. However, this aspect is not relevant for what I have in mind.

Why am I bringing up this issue on social mirrors to a blog on technology and people?

I have been thinking for a while on how can technology be used to enhance the human condition. Of course, technology has already done a lot in both economical and social terms; evolution of human societies cannot be dissociated from technology. However, there is place for improvement, in particular in a world where people is overwhelmed by information that they cannot master. In this world it is becoming increasingly difficult to get answers for some question. How are my taxes being used? How can I take control of my information on the internet? And so on and so forth.

While I was thinking on a name for a software application that would allow people to steer their own public image, and ensure some fairness among all concerned, the name SocialMirror came up.

Then I googled for "social mirror" to know whether the name was already taken by another application. Curiously, and in life very often meaning comes after action, I found the social mirror theory.

I envisage an endless game of mirrors where awareness is being continuously reshaped. Mirrors reflect each other and each one adds a bias (see post on a young girl). This bias occurs due to some some new element, either a new external (real) fact or new social construction.

In another post I will address the challenges for the design of a SocialMirror software application.

O software como uma construção social

Por vezes, ao preparar as aulas, volta-se a reler os mesmos artigos, e há frases, ou palavras, que sempre lá estiveram e parece que não tínhamos reparado. No artigo Who Needs an Architect?, Martin Fowler, diz que a arquitectura de software, assim como o software é um social construct. Quando desta vez voltei a ler o artigo fiquei com curiosidade de ver com detalhe qual a definição de construção social.

Segundo o Wikipedia, a social construction (social construct) is a concept or practice that is the construct (or artifact) of a particular group. When we say that something is socially constructed, we are focusing on its dependence on contingent variables of our social selves rather than any inherent quality that it possesses in itself.

Ignorando o aspecto de negar a essência do produto, que algumas teorias sócio-técnicas mais recentes levam em consideração, o que é ressalta desta definição é que de facto o desenvolvimento de software não é, nem nunca poderá ser, rocket science.

Assim, Martin Fowler termina o artigo dizendo que: "Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world. “We have met the enemy, and he is us.”"

Com base nesta frase pergunto aos alunos se não será o frustrante fazer engenharia de software? Ao que um aluno me diz que não, antes pelo contrário, esta é uma oportunidade para se poder ser mais criativo.

Agora que vou viajar...

Consulto a pasta de correio electrónico onde fui juntando toda a correspondência relativa à preparação da viagem. Já algum tempo que deixei de usar as pastas do sistema operativo para guardar a informação relacionada com a colaboração com outras pessoas. A quase totalidade da informação que recebo chega através de correio electrónico. Inclusivamente, por vezes, vejo-me na necessidade de enviar mensagens a mim próprio para juntar numa pasta de correio electrónico onde se encontra informação relacionada. 

Ainda assim, esta solução não é completamente do meu agrado. Levo algum tempo a encontrar a informação. Em particular, no contexto desta viagem, sempre que acedo à pasta  tenho um período inicial em quem vou percorrendo a informação e, mentalmente, a vou agrupando de acordo com o meu interesse do momento, seja a reserva de hotéis ou a distribuição da informação de acordo com o calendário da viagem. Por outro lado, começo a ter várias versões da mesma informação é necessário perceber qual é a que me interessa neste caso, não necessariamente a mais recente.

Muita da informação sobre a viagem resulta da utilização de serviços externos, como sejam serviços de reserva de hotel, avião e automóvel. Estes serviços enviam-me mensagens com os vouchers. Ou seja, alguma da informação que possuo na minha pasta de correio electrónico é apenas uma duplicação, não actualizada, da informação real. Por exemplo, se desejar saber se a viagem de avião alterada devo procurar na minha pasta a referência para o sítio onde o serviço está disponibilizado.

Idealmente, gostaria de poder ter a integrada a informação sobre a viagem com as trocas de mensagens de correio electrónico que efectuei para a preparar. Infelizmente, agora tenho de decidir por duas opções, ou conservo a informação dentro das mensagens ou a desagrego das mensagens. Ambas as soluções não me agradam, embora tenha pendido mais para a primeira.

Há cerca de 2 anos a Google lançou uma ferramenta revolucionária chamada Google Wave. Esta ferramenta permite que várias pessoas colaborem através da troca de mensagens e que simultaneamente vão sintetizando e agregando a informação que vai sendo trocada nas mensagens. Era objectivo da Google alterar o paradigma de comunicação actual, baseada no correio electrónico, por um paradigma de maior partilha e construção colaborativa de conteúdos. Esta proposta acabou por não vingar e acabou por ser abandonada pela Google. 

O Google Wave tem as potencialidades desejadas. Contudo sinto a necessidade de poder ter entidades estruturadas. Tal como o correio electrónico, o Google Wave apenas considera conteúdos feitos de texto e blobs (imagens, videos, etc). Na preparação da viagem gostaria de poder criar um entidade reserva de hotel para cada reserva. Também gostaria de poder enviar um pedido de informação sobre um local que desejo visitar já com um formato pré-estabelecido, de forma a que a resposta criasse uma entidade informação de local que eu poderia depois complementar com a indicação do hotel onde iria ficar e a referência para as coordenadas no Google Maps. A utilização de entidades estruturadas, ligadas a um contexto de comunicação, permitiria usar ferramentas de pesquisa e a ligação a serviços externos. Por exemplo, a entidade reserva de avião, ligada ao serviço externo de reserva de voo, iria sendo actualizada com o estado do voo.

Razão e Coração

Começam a ser publicadas comparações entre o Google+ e o Facebook, e o como o Google+ poderá contrariar o crescimento do Facebook. Nas razões para usar o Google+ é dado ênfase à facilidade de utilização e a uma melhor gestão da privacidade da informação.

O Facebook, que nasceu como uma aplicação para conhecer miúdas, atinge agora os 750.000.000 de utilizadores. De algum modo, ainda não perdeu essas feições do coração.

Qual é a estratégia da Google para construir a sua rede social e substituir a do Facebook?

Duas estratégias são possíveis: tomar de assalto a rede Facebook, fazendo que as pessoas a abandonem e passarem a usar a rede Google+, ou criar um novo tipo de rede, que inicialmente atraia pessoas que não são utilizadoras usuais do Facebook, e que incrementalmente vá conquistando utilizadores ao Facebook.

A primeira estratégia, ilustrada neste cartoon, é equivalente a convencer 750 milhões de clientes de uma discoteca famosa e se mudarem em bloco para a discoteca ao lado. Dado que a discoteca está vazia, pode-se sugerir que lá se defende mais a privacidade das pessoas, mas é um argumento fraco, até porque vão todas à mesma discoteca para se poderem ver e comentar.

A segunda estratégia estará mais em sintonia com a forma como se cria inovação, segundo The Innovator's Dilemma. Por exemplo, a maior garantia de privacidade deverá permitir o surgimento de uma comunidade que não se reveja na rede Facebook. Esta comunidade ganhará identidade autónoma e tornat-se-à atraente aos olhos dos utilizadores Facebook que paulatinamente mudarão de comunidade.

O Google, dada a sua dimensão e capacidade tecnológica, parece estar a tentar a primeira estratégia, usar a força da razão para tomar de assalto a comunidade Facebook. No entanto, pode acontecer que algum embrião de comunidade se sinta atraído pelas possibilidades das novas funcionalidades do Google+, e as coisas aconteçam de outra forma.

No man is an island

Investigação realizada com as moscas da fruta parece indicar que uma mosca que perdeu diversas disputas tem tendência a perder as disputas seguintes, ainda que com oponentes mais fracos. 

A Google acabou de lançar o Google+, uma tecnologia de suporte a redes sociais, para competir com o Facebook.

Segundo algumas opiniões o que está em disputa é a identidade.

Durante algum tempo olhou-se para a identidade digital na perspectiva da identificação. Como identificar de forma única os utilizadores da web? Como simplificar o processo de autenticação, fazendo que apenas seja necessária uma senha de entrada, para aceder a um vasto conjunto de serviços electrónicos? Um exemplo é o Windows Life ID.

A identificação digital única tem algumas vantagens. Mormente ao utilizador final, que não tem que gerir diversas identificações e senhas de entrada, mas também às empresas que concorrem para gerir as identificações, através de um complexo processo de fidelização de clientes e, consequentemente, de fornecedores de serviços, como a VISA ou a MasterCard.

Mas o modelo de negócio da Google foi alargar a identidade para além da identificação. O modelo de informação que a Google possui para cada utilizador da web é uma identidade gerada com as acções que cada um efectua quando usa o seu software. Esta identidade permite uma maior eficácia e precisão na identificação de quais os produtos que nos interessam. É essa eficácia que a Google vende às empresas que a contratam para difundir publicidade.

Também para o Facebook a identidade é feita da informação que possui acerca de cada um de nós, mas, contrariamente à Google, essa informação é explicitamente agregada pelos utilizadores. Quando se decide que fotografias se coloca no mural e que amigos se aceita estamos a definir explicitamente a nossa identidade.

Daqui resultaram dois modelos muito diferentes. No primeiro caso deixamos que a Google nos indique que informação nos interessa, no segundo caso "perguntamos" aos nossos amigos.

De forma um pouco inesperada, como referi em A Face de todas as Faces, actualmente as páginas web são mais acedidas a partir de páginas do Facebook do que de pesquisas no motor do Google. E isso, naturalmente, preocupa a Google. Daí a necessidade de passar de um modelo de identidade gerada para um modelo, ala Facebook, em que o utilizador constrói a sua identidade. Ou seja, a estratégia de oferecer um conjunto aparentemente "desgarrado" de aplicações, aparentemente, pois a informação sobre o seu uso é constantemente agregada em segundo plano para gerar a identidade, não funciona dado que não permite ao utilizador agregar a sua informação.

O Google+ integra numa interface única a possibilidade de agregarmos a nossa informação, construirmos a nossa identidade. Está anunciado como um processo em que incrementalmente novas aplicações Google serão integradas nesta interface única. A Google dá a informação que possui acerca de nós para dizermos quem somos.

Das Reputações

No final da guerra Irão-Iraque, Saddam Hussein usou gás contra a sua própria população, este episódio é conhecido como o massacre de Halabja. Deste massacre foram recolhidas imagens das pessoas gaseadas em ruas desertas, tendo estas imagens sido difundidas pelos meios de comunicação social. Contudo, apenas dois anos mais tarde estas imagens ganharam maior impacto quando, após a invasão do Kuwait, elas foram re-difundidas e referenciadas no contexto de um outro discurso.

A reputação é um elemento essencial das interacções humanas. Funciona como a base sobre a qual acontecem as interacções. Com a globalização e virtualização das interacções também os mecanismos de criação e manutenção de reputação tiveram necessidade de se globalizar e virtualizar.

A reputação de uma pessoa, ou instituição, está directamente ligada à informação que possuímos acerca dessa entidade. Adicionalmente, juntamos uma valoração própria, construída a partir da interpretação que fazemos dessa informação e usando os nossos princípios.

É (era) assim, nas pequenas comunidades rurais, onde toda a gente se conhece e onde as alcunhas representam uma cristalização da valoração. Esta cristalização acaba por ser partilhada por todos, à medida que a alcunha vai sendo adoptada. A alcunha, uma valoração acerca da informação, transforma-se em informação, podendo ser sujeita às mesmas transformações que são efectuadas sobre a informação.

Também nas comunidades virtuais os mecanismos de reputação são essenciais. Neste artigo refere-se a importância dos mecanismos de reputação para as comunidades virtuais onde há transacções comerciais. No entanto, os mecanismos de reputação também têm impacto em outros aspectos das comunidades virtuais. Por exemplo, na Amazon a reputação de quem escreve revisões ajuda a formar opinião sobre as obras. Os top reviewers funcionam como alcunhas de quem faz revisões. Um top reviewer é aquele cujas revisões mais pessoas acharam úteis.

Mas a reputação não se aplica apenas a pessoas, também as páginas web têm associado um mecanismo de reputação. Por exemplo, a ordem pela qual são apresentados os resultados de uma pesquisa utilizando o motor de pesquisa da Google depende da reputação da página, page rank. Neste caso, a reputação de uma página é dada não apenas pelo número de páginas que a referenciam, mas também pela reputação das páginas que a referenciam. Uma página pode não ser referenciada por muitas páginas e ter uma reputação elevada, desde que seja referenciada por páginas com reputação alta.

É interessante observar que estes algoritmos pretendem simular um funcionamento semelhante ao funcionamento dos mecanismos de reputação em contextos não digitais. E tal como no contexto não digital, a reputação digital pode ser (é) alvo de tentativas de manipulação, pelo qual vão sendo propostos novos algoritmos que procuram colmatar as falhas encontradas.

Dr. Strangesoftware

Stanley Kubrick, no filme Dr. Strangelove, constrói uma situação em que os homens ingloriamente lutam contra os procedimentos que criaram. Estes procedimentos, uma vez activados, iniciam uma processo que se revela impossível de parar, levando à destruição da vida no planeta terra. Esta história, é uma versão soft do tema que foi recorrente na ficção científica sobre a tentativa da máquina controlar o seu criador, o homem. Nestas histórias ilustra-se a luta entre a lógica e o humano.

Numa história real, Barbara Tuchman descreve num livro sobre o primeiro mês da Grande Guerra, The Guns of August, como o Kaiser, poucas horas depois de ter ordenado o início das operações contra a França, resolve, após receber um telegrama do seu embaixador em Londres, alterar a sua decisão e invadir a Rússia. A invasão da França tinha sido logicamente preparada para ocorrer em 6 semanas, o que implicava um minucioso plano de deslocação de cerca de 1.000.000 de homens, usando os caminhos de ferro. Quando o Kaiser comunica a sua decisão ao seu chefe do estado maior, a resposta que recebe foi, escreve Tuchman: 

"Your Majesty, it cannot be done. The deployment of millions cannot be improvised. If Your Majesty insists on leading the whole army to the East it will not be an army ready for battle but a disorganized mob...". 

O Kaiser não teve poder para parar a máquina que tinha colocado em marcha.

Também no software há este paradoxo entre a coisa criada e o criador, entre a lógica e o humano.

Num artigo recente na ACM Software Engineering Notes, Robert Schaefer descreve magistralmente este paradoxo:

"I’ve also been thinking a lot lately about the kinship that software developers and managers have in regards to the parable of the blind men and the elephant. Software, as an object stripped away from culture, can be reduced to mathematics, a culturally valueless set of rules of manipulation of symbols. Software also is the formalization of ideas into logic. Coding is nothing more than thinking clearly and logically in the process of symbol manipulation. If so, then what is the big deal? Why can’t just anyone write programs and logic be damned? Logic has one set of rules and culture another. Logic must, but cannot be, separated from cultural values (another paradox). The attempt to map cultural values onto logic, while denying that we are doing it as we do it, is where trouble begins. Now the blind men weren’t able to see the elephant all at once, they could only guess at parts through touch, and emphasize the attributes, assume the whole of a part. We though, as designers and programmers can see the whole elephant, but are not much better off. Which more or less ruins the elephant analogy. Unless the elephant we see is not the elephant that is. Then the elephant analogy works again. We model the elephant in our minds, but the elephant that is, is something different. It looks like an elephant, but behaves like something else. In this instance, it looks like logic but behaves like culture."

Há, no entanto, uma diferença fundamental relativamente às máquinas e procedimentos que têm por base uma visão científica enraizada em princípios desenvolvidos ainda no século XIX: no software a coisa criada não é externa ao criador, não existe para além dele.

Dessa propriedade do objecto de software, que é a sua apropriação pelas pessoas, para além da lógica, falo em alguns dos posts. Por exemplo Da desordem à ordem natural das coisas é sobre a necessidade de tornar a codificação da cultura mais integrada com a codificação da lógica.

Onde começa a produtividade

Depois da inovação vem a produtividade. Temos que ser mais produtivos. Mas, conseguiremos ser tão produtivos a produzir cortiça como os Alemães a produzir automóveis?

A produtividade é definida como a relação entre a produção e os factores de produção utilizados. Ou seja, quanto mais produzirmos, usando menos recursos, mais produtivos seremos. Mas terá que ser necessariamente assim? 

No seu livro Predictably Irrational, Dan Ariely descreve o caso das pérolas negras que se tornaram num bem de luxo após terem sido expostas numa montra da 5ª Avenida de Nova Iorque, com um preço exorbitante. A produtividade aumentou consideravelmente.

Durante muitos anos procurou-se que o processo de desenvolvimento de software fosse como um processo industrial de produção de bens. Este processo caracteriza-se por tentar que o factor humano se torne similar aos restantes factores, como seja a matéria prima. Por exemplo, se aumentarmos a quantidade de matéria prima e reduzirmos o seu custo, podemos aumentar a produção e a produtividade. O mesmo raciocínio aplica-se ao trabalho humano. Quando este processo é bem sucedido é até possível substituir trabalho humano por trabalho automatizado, por exemplo usando robots. 

Contudo, logo nos anos 70, começou a haver indicações que para o desenvolvimento de software poderia não ser possível aplicar as mesmas regras. Fred Brooks observou que adicionar mais pessoas a um projecto de software que está atrasado relativamente ao planeado ainda o atrasa mais, o que é conhecido como a Lei de Brooks.

Não obstante esta constatação, continuou-se durante mais cerca de 20 anos a tentar industrializar o processo de desenvolvimento de software. Após os sucessivos insucessos, surgem, no final do anos 90, propostas de ágeis para o desenvolvimento de software que negam muitas das práticas industriais clássicas. Estas propostas, em vez de lutarem contra a intangibilidade do software, e consequente  dificuldade em o medir, procuram tirar partido dessas características. Assim, propõem um desenvolvimento pronto para se adaptar à mudança e dela tirar partido. 

Os métodos ágeis percebem que a produtividade no desenvolvimento de software não está na quantidade do produto mas na sua qualidade e, muito em particular, no seu impacto. Em onde Onde pára a inovação falo sobre o caso do Facebook.

Ou seja, na produção de certos tipos de produtos a produtividade começa na inovação.

Por outro lado, a palavra produtividade tem um peso histórico. Especialmente quando se torna programática, na forma de batalha da produção. Na batalha da produção do aço na China, durante o grande salto em frente, o resultado foi a produção de grandes quantidades de aço, de baixa qualidade, e que não servia para nada. Nestas batalhas, na memória, ficam apenas os culpados das derrotas anunciadas e os heróis das vitórias que foi necessário inventar.

Onde pára a inovação

Há palavras que valem mais do que outras. Palavras que adquirem um valor que ultrapassa o seu significado. Normalmente um valor emotivo ao qual é difícil ficar indiferente, até por este ser partilhado por um grupo.

Estas palavras têm uma função importante, são mobilizadoras e desencadeiam comportamentos. Contudo, dado que o seu valor ultrapassa o seu significado, estes comportamentos podem não ter um fundamento na realidade. Esta situação não é necessariamente negativa, por exemplo algumas teorias económicas defendem que o optimismo do mercado é fundamental para o crescimento. O difícil é perceber a fronteira entre o optimismo e a bolha que ele pode criar.

Uma palavra que ganhou nos últimos anos algum deste efeito placebo, é a palavra inovação (sobre o efeito placebo associado ao valor ver Why a 50-cent aspirin can do what a penny aspirin can't de Dan Ariely). Ainda é cedo para avaliar se os comportamentos gerados criaram as sinergias necessárias e se estas tiveram de facto um impacto social e económico, mas, a palavra também funcionou como um agente de esperança.

No clássico The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail, Clayton M. Christensen estudou a indústria dos discos de computador. Esta indústria teve ciclos de inovação muito rápidos entre os anos 70 a 90. Ele observou que, nas empresas que foram sucessivamente perdendo a corrida pela inovação, a gestão fez o que devia ter feito, esteve centrada nas necessidades dos clientes. E, paradoxalmente, a tecnologia inovadora deve origem nessas empresas, ou então, elas tinham os conhecimentos necessários para criar a tecnologia inovadora. O que se passou foi que os seus clientes não estavam interessados na nova tecnologia.

As empresas que inovaram foram aquelas que descobriram/criaram clientes para a tecnologia. Estes clientes permitiram criar um novo mercado. Neste mercado a nova tecnologia aperfeiçoa-se e acaba por integrar o mercado dos clientes que inicialmente eram reticentes à mudança tecnológica. Quando isso acontece, as empresas que eram dominantes são destronadas pelas empresas emergentes.

A engenharia de requisitos é a fase do desenvolvimento de um sistema de informação em que se identificam as necessidades do cliente e se escreve uma especificação do sistema de informação a desenvolver. Dada a imaterialidade do software e a complexidade do contexto onde o problema existe, o engenheiro de requisitos tem bastante margem de manobra para criar/influenciar a definição do problema.

Nesta fase de engenharia de requisitos é possível inovar, no sentido em que é possível reformular o problema num contexto não previsto pelo cliente. Alguns gurus da engenharia de requisitos chamam a isto inventar requisitos. 

Esta diferença entre a engenharia de software e as engenharias mais clássicas está relacionada com a capacidade de um sistema de informação criar/alterar uma linguagem, como referi em A linguagem da informação. O que pode incluir alterar o significado de palavras, veja-se a palavra amigo no Facebook. Por outro lado, para ser inovador, um sistema de informação pode não necessitar de tecnologias disruptivas. Em A Face de todas as Faces refiro que a complexidade funcional do Facebook é diminuta e a sua complexidade tecnológica é o resultado do seu sucesso, necessidade de fornecer serviços a um grande número de utilizadores, e não a sua causa.

A linguagem da informação

O desenvolvimento do sistema de informação para o registo electrónico de pacientes no Reino Unido, Public procurement: Only the bare bones, é mais um caso sintomático das dificuldades de desenvolvimento de sistemas de informação. Lançado com pompa e circunstância, arrasta-se agora carregando o seu manto de dinheiro.

O caso tem algumas semelhanças com o descrito em Do público e Do privado. Mas, há uma questão interessante que é levantada na notícia. O registo electrónico de pacientes é um objectivo inquestionável, que todos concordam ser necessário, mas parece não ter solução. A abordagem centralizada falhou, mas a delegação nas unidades de saúde também não parece trazer, refere um responsável, os resultados desejados.

Stephen Pinker, no seu livro How the Mind Works, defende que a linguagem é inata, é um órgão. Existe um período no crescimento humano em que esse órgão se modela para criar a linguagem. Num exemplo, adultos que têm contacto tardio, embora prolongado, com outra língua têm dificuldade em construir frases que não tenham ambiguidades, enquanto que os seus filhos criam uma língua própria (crioulo), ainda que possuindo simplificações gramaticais, por junção de elementos da língua materna e da língua exógena, e com a qual constroem frases sem ambiguidades.

A actividade dos profissionais de saúde implica uma grande responsabilidade pois das suas acções pode depender a vida humana. Frequentemente essa responsabilidade é a título individual e resulta das interacções directas e pessoais entre o profissional e o paciente. Nestas interacções a linguagem é um elemento importante e pode ganhar um carácter único, quer associado ao profissional, quer associado à sua interacção com o paciente. A tentativa de normalizar essa linguagem entre os profissionais não é uma tarefa fácil.

A definição de normas em sistema de informação também não tem sido uma tarefa fácil, embora seja percebida por todos como necessária. Tem havido duas abordagens, a abordagem centralizadora e a abordagem de consenso. A abordagem de centralizadora acontece quando uma tecnologia se torna hegemónica e fica a norma de facto. A vantagem desta abordagem é que não necessita de criar compromissos tecnológicos, pelo que frequentemente a tecnologia é mais simples. Por consenso acontecem duas situações, por um lado a tecnologia vai ter de integrar muitos compromissos, pelo que ficará mais complexa, e por si só não assegura que irá ser adoptada. O comité de normalização pode ser o local onde os vários interessados medem forças (disputa de memes).

A tecnologia existe para satisfazer as necessidades das pessoas e o seu uso, e muito em particular o uso da tecnologia da informação, está intimamente ligado à sua linguagem. Um dos aspectos centrais do desenvolvimento de um sistema de informação é a criação, ou alteração, de uma linguagem.