Frameworks? Plataformas? Ambientes?

E antes: máquinas, linguagens, sistemas operacionais.

Modelos de programação (de máquina universal) cada vez mais complexos, distantes da máquina universal Turing, Von Neuman e outras.

1. Framework: mais que o sistema operacional, mais que a linguagem, isola programadores, impede o uso de componentes, amarra programadores a um fabricante (Microsoft, Java, ...). E mais uma vez é um ambiente baixo nível, com componentes "pequenos". A cada vez o programador tem que cuidar de detalhes, e não da arquitetura da aplicação.

Sem falar das IDEs que vem junto, que fazem o programador ser muito mais um organizador de componentes em bibliotecas do que um elaborador de algoritmos. Trabalha num ambiente inerentemente frágil, está limitado pelo ambiente, e é o tempo todo impelido a "não codificar". "Veja como é fácil fazer x ou y sem escrever uma linha de código".

2. Plataforma: passo além do framework, voltamos à guerra de ambientes que eram os sistemas operacionais: Android, IOS, Windows Phone.

Mas... vejam Modern Cross Platform Development : coloca o problema e depois mostra diversas soluções cross platform.

E ainda aponta para a Web como A plataforma. O programador deveria desenvolver para a Web. A ver a referência que ele dá: "As Jeff Atwood discusses in his seminal blog post All Programming is Web Programming; "the web is the most efficient, most pervasive, most immediate distribution network for software ever created - its almost completely frictionless"."

The Framework Myth

If ever there was an irresistible programmer’s platitude, it is that code-reuse is invariably a good thing. Unfortunately, even the best of advice can be taken to a ludicrous extreme, the construction of generic frameworks within organisations.  Mike Mooney gives a warning, based on painful experiences.

Clearly shows, trough both practice and reflection, that attempt to build framework will impact negatively software development. So, back to the simple programming model, don't try to invent shortcuts. Either you are not good enough or the framework built will not be good enough for the job.

Why Can't Developers Estimate Time?

Some thoughts on estimating projects time, and the very important sentende: We can't estimate the time for any individual task in software development because the nature of the work is creating new knowledge.

Not Dead Yet: The Rise and Fall and Rise of Java

Java is not dead yet, but new and diverse languages are rising. Good market study with statistics.

Fact and folklore in software engineering

Laurent Bossavit questiona e critica as várias análises e teorias sobre produtividade do programador. O assunto aparece no tópico So what is known about programmer productivity? Resposta: muito pouco. Quando se tem medidas que variam de 1 a 20, pode-se dizer que não se sabe nada e que não há métricas úteis. Temos um campo de estudo pouquíssimo científico, baseado em folklore e  "ouvi dizer". Que tal reconhecer que programar não é um tipo de trabalho cuja produtividade se mede? É mais próximo de trabalho criativo, de arte, de produção de ciência, de produção de matemática.

Também  em francês aqui.

Programabilidade é fundamental

It is no exaggeration to regard this as the most fundamental idea in programming:

The evaluator, which determines the meaning of expressions in a programming language, is just another program.
 

To appreciate this point is to change our images of ourselves as programmers. We come to see ourselves as designers of languages, rather than only users of languages designed by others.

Structure and Interpretation of Computer Programs, Harold Abelson and Gerald Jay Sussman, The MIT Press, 2nd edition, 1996, p.297

IDEs: precisa? Ajudam? Atrapalham?

So long and fare well to the IDE

Diz praticamente tudo sobre IDEs. Tudo de ruim. Para um programador, basta um editor de textos.

E vai mais longe. Para um programador, o importante é a abstração. É construir ferramentas à medida em que econtra problemas.

Nada de esquemas prontos, nada de preenchimento automático. Isto é para codificadores. Programador cria.

Program or be Programmed

Douglas Rushkoff, Program or be Programmed: Ten Commands for the Digital Age

Visão radical, mas que me parece muito correta. Análise histórica: na Antiguidade, com invenção da escrita, o poder é dos escribas. O resto do povo ouve. Continua a análise histórica, e chega à invenção da máquina universal, o computador. Programável. O poder é de quem sabe programar. O resto do povo usa programas prontos.

Instigante.

Me parece corretíssimo. Ou temos software programável, aberto, acessível, passível de evoluir. Ou seremos meros usuários.

Tem analogias com o ensaio de Vilém Flusser: Texto/imagem enquanto Dinâmica do Ocidente.

Programar é difícil

Some lesser-known truths about programming

Menos conhecidas? Muito importantes e pouco comentadas. Programador tem que trabalhar muito. Programar é difícil. Programador tem que pensar. Há diferenças de produtividade imensas entre bom programador e mau programador.
 

Esta última mostra que programar está mais próximo de criação do que de trabalho sistemático, mais para arquitetura que para engenharia. O que acaba com o mito da engenharia de software.
 

Software é desenvolvido por indivíduos, não por equipes. As várias metodologias que falam em peer programming devem ser reconsideradas.
 

O artigo cita o estudo do Standish Group que mostra melhoras no índice de sucesso de projetos de software. Cuidado, os critérios do Standish Group não são claros, a amostra cobre projetos muito diferentes, e a própria definição de projeto é discutível. Pergunta: a melhora foi na produtividade em software ou no gerenciamento de projeto?
 

Programar é trabalho pesado: as inúmeras formas de "facilitar" a programação, via IDEs, linguagens "fáceis", frameworks prontos, iludem o candidato a programador. Não há caminho suave para um trabalho que exige reflexão.