Porquê?
No seguimento do meu último artigo...
Desenvolver software não é apenas uma questão de se ser bom engenheiro[1] e/ou bom programador, também é necessário ter uma boa equipa de QA. E é aqui que eu julgo estar o problema do Linux no desktop.
Nível "Servidor"
Nos primeiros tempos do movimento opensource, talvez se pudesse argumentar que o software de nível servidor era mais robusto por ser mais simples de testar e mais determinista na sua utilização, mas hoje em dia esse argumento já não pega na maioria dos casos, pois projectos como o Apache, Apache Tomcat, MySQL, PostgreSQL e suas interacções com Python, PHP, PERL, etc. tornam-nos em algo de elevada complexidade em termos de base de código, mas também em termos de interacções. No entanto continuam a ser robustos, sem deixarem de incorporar novas funcionalidades.
O que acontece é que este tipo de software se tornou bastante popular, e é usado todos os dias, 24h por dia em centenas de milhar de instalações em todo o mundo com centenas de milhões de utilizadores, e as empresas que fornecem serviços ou produtos baseados nestes projectos, acabam por fazer o trabalho de QA, detectando falhas, notificando os developers de uma forma estruturada, ou participando na correcção dos problemas, caso tenham developers próprios.
Nível "Embedded"
O nível dos dispositivos embebidos pode ser racionalizado da mesma forma que o nível servidor. Se empresas como a MontaVista não tivessem o cuidado de garantir a qualidade dos seus produtos, hoje não existiriam centrais GSM ou equipamento de comunicações a correr Linux (algo que obriga a uma fiabilidade e robustez acima da média).
Nível "Desktop"
No nível desktop isto já não acontece. Ainda são poucas as empresas que fornecem serviços ou produtos orientados para o desktop baseados em Linux. Sendo assim, o QA organizado é também reduzido, pois a maioria dos utilizadores faz bug reports sem se preocupar em tentar dissecar o problema até ao máximo das suas possibilidades, e não há gente suficiente dedicada apenas a esta tarefa. Se juntarmos a isto o ritmo extremamente rápido de desenvolvimento das aplicações, não podemos esperar milagres. Acrecentam-se funcionalidades em cima de funcionalidades sem se corrigirem todos os bugs, o que é o inverso do que ocorre no nível servidor ou embebido.
Mudança Precisa-se
Eu diria que isto tem de mudar, os GNOMEs e KDEs que andam por aí têm de mudar para um processo mais iterativo e gradual, onde a adição de novas funcionalidades ocorre ao mesmo ritmo a que se corrigem bugs. Se isto significar um avanço mais lento, então que seja, não serve de nada um ambiente cheio de funcionalidades que funcionam mal ou erraticamente. Pouca funcionalidade e poucos bugs é mau, mas muita funcionalidade e muitos bugs é capaz de ser pior. É imperativo encontrar um meio termo, porque a manter-se o panorama actual, estamos a caminhar a grande velocidade para o descrédito e a ruína.
Podemos tomar como exemplo as distribuições "mainstream". O ritmo de lançamento é demasiado acelerado, e com demasiados saltos entre versões. Devia haver apenas um lançamento por ano, com bug fixes e updates de funcionalidade graduais entretanto.
O que acontece hoje, é que uma nova versão é lançada e imediatamente passa para o fundo da lista das prioridades, com a correcção dos problemas a ser adiada para a próxima versão, altura em que se descobrem novos problemas e assim por diante...
Para finalizar, porque é que a seguir a um GNOME 2.6.0 vem um 2.6.1 com meia dúzia de bug fixes e depois saltam logo para um 2.8.0 com montes de alterações internas (o eterno rewrite from scratch) e novas funcionalidades? Porque não lançar um 2.6.2 com bug fixes e pequenas funcionalidades novas, e depois um 2.6.3 e apenas saltar para um 2.8.0 quanto fosse realmente necessário fazer alguma alteração radical?...
Pensem nisto...
[1] No verdadeiro sentido da palavra, um tipo com competência, conhecimentos e engenho, e não o título a que só têm direito os que pagam as quotas da Ordem dos Engenheiros (organização com a qual não concordo - do ponto de vista da Engenharia Informática - mas as razões ficam para outro dia), mesmo que tenham uma licenciatura em Engenharia acreditada pela própria Ordem...
Desenvolver software não é apenas uma questão de se ser bom engenheiro[1] e/ou bom programador, também é necessário ter uma boa equipa de QA. E é aqui que eu julgo estar o problema do Linux no desktop.
Nível "Servidor"
Nos primeiros tempos do movimento opensource, talvez se pudesse argumentar que o software de nível servidor era mais robusto por ser mais simples de testar e mais determinista na sua utilização, mas hoje em dia esse argumento já não pega na maioria dos casos, pois projectos como o Apache, Apache Tomcat, MySQL, PostgreSQL e suas interacções com Python, PHP, PERL, etc. tornam-nos em algo de elevada complexidade em termos de base de código, mas também em termos de interacções. No entanto continuam a ser robustos, sem deixarem de incorporar novas funcionalidades.
O que acontece é que este tipo de software se tornou bastante popular, e é usado todos os dias, 24h por dia em centenas de milhar de instalações em todo o mundo com centenas de milhões de utilizadores, e as empresas que fornecem serviços ou produtos baseados nestes projectos, acabam por fazer o trabalho de QA, detectando falhas, notificando os developers de uma forma estruturada, ou participando na correcção dos problemas, caso tenham developers próprios.
Nível "Embedded"
O nível dos dispositivos embebidos pode ser racionalizado da mesma forma que o nível servidor. Se empresas como a MontaVista não tivessem o cuidado de garantir a qualidade dos seus produtos, hoje não existiriam centrais GSM ou equipamento de comunicações a correr Linux (algo que obriga a uma fiabilidade e robustez acima da média).
Nível "Desktop"
No nível desktop isto já não acontece. Ainda são poucas as empresas que fornecem serviços ou produtos orientados para o desktop baseados em Linux. Sendo assim, o QA organizado é também reduzido, pois a maioria dos utilizadores faz bug reports sem se preocupar em tentar dissecar o problema até ao máximo das suas possibilidades, e não há gente suficiente dedicada apenas a esta tarefa. Se juntarmos a isto o ritmo extremamente rápido de desenvolvimento das aplicações, não podemos esperar milagres. Acrecentam-se funcionalidades em cima de funcionalidades sem se corrigirem todos os bugs, o que é o inverso do que ocorre no nível servidor ou embebido.
Mudança Precisa-se
Eu diria que isto tem de mudar, os GNOMEs e KDEs que andam por aí têm de mudar para um processo mais iterativo e gradual, onde a adição de novas funcionalidades ocorre ao mesmo ritmo a que se corrigem bugs. Se isto significar um avanço mais lento, então que seja, não serve de nada um ambiente cheio de funcionalidades que funcionam mal ou erraticamente. Pouca funcionalidade e poucos bugs é mau, mas muita funcionalidade e muitos bugs é capaz de ser pior. É imperativo encontrar um meio termo, porque a manter-se o panorama actual, estamos a caminhar a grande velocidade para o descrédito e a ruína.
Podemos tomar como exemplo as distribuições "mainstream". O ritmo de lançamento é demasiado acelerado, e com demasiados saltos entre versões. Devia haver apenas um lançamento por ano, com bug fixes e updates de funcionalidade graduais entretanto.
O que acontece hoje, é que uma nova versão é lançada e imediatamente passa para o fundo da lista das prioridades, com a correcção dos problemas a ser adiada para a próxima versão, altura em que se descobrem novos problemas e assim por diante...
Para finalizar, porque é que a seguir a um GNOME 2.6.0 vem um 2.6.1 com meia dúzia de bug fixes e depois saltam logo para um 2.8.0 com montes de alterações internas (o eterno rewrite from scratch) e novas funcionalidades? Porque não lançar um 2.6.2 com bug fixes e pequenas funcionalidades novas, e depois um 2.6.3 e apenas saltar para um 2.8.0 quanto fosse realmente necessário fazer alguma alteração radical?...
Pensem nisto...
[1] No verdadeiro sentido da palavra, um tipo com competência, conhecimentos e engenho, e não o título a que só têm direito os que pagam as quotas da Ordem dos Engenheiros (organização com a qual não concordo - do ponto de vista da Engenharia Informática - mas as razões ficam para outro dia), mesmo que tenham uma licenciatura em Engenharia acreditada pela própria Ordem...
Carlos Rodrigues - 22.11.04 |
permalink
Então achas que quem tem um curso acreditado pela ordem não devia pagar quotas?
Então só pagava quem lá entrasse "por exame" ?
Por
Anónimo, em 23 Novembro, 2004 18:19
Não, eu simplesmente não vejo nenhuma utilidade para a Ordem dos Engenheiros, sob o ponto de vista da engenharia informática.
E a questão das quotas não é essa. A questão é que um licenciado num curso de engenharia acreditado pela Ordem, não pode usar o título de Engenheiro (é crime, segundo a lei) e tem de fazer um estágio de 6 meses para lá poder entrar.
Por
Carlos Rodrigues, em 23 Novembro, 2004 18:42
Sim eu concordo que não fazem muito sentido do ponto de vista da informática. Há sempre quem goste de dizer que é engenheiro, portanto... nem que seja por essas pessoas.
Desde que eles não metam com ideias de limitar o acesso à profissão, como fazem com civil, que fiquem por lá com os elitismos deles que não me chateiam.
Por
Anónimo, em 23 Novembro, 2004 19:17
As limitações de acesso à profissão são restos de corporativismo e auto-proteccionimo ridículo que não fazem sentido nenhum. As ordens fazem sentido para os médicos e advogados onde as dicussões sobre a ética e a sua manutenção têm importância fulcral. Nas engenharias não faz sentido, já está mais que demonstrado que a sociedade (profissionais do ramo, pertencendo ou não à Ordem) conseguem gerir-se sozinhos.
Por
Carlos Rodrigues, em 23 Novembro, 2004 19:28
Sobre títulos, engenharias e etc., fica uma afirmação para reflectir: se estivessemos nos EUA ou no Reino Unido, eu seria um Software Enginneer mas como estamos em Portugal não passo de um programador.
Como dizia o outro: sou engenheiro por vocação e não por formação. ;-)
Por
Anónimo, em 24 Novembro, 2004 11:46
Exacto. E curiosamente os títulos em Portugal até dão alguns problemas na interacção com o estrangeiro. A AIP até aboliu os títulos internamente por causa disso, porque os senhores doutores e engenheiros não achavam piada aos espanhóis mandarem correspondência sem os usar. Assim acabou-se a festa de uma vez.
Por
Carlos Rodrigues, em 24 Novembro, 2004 15:52