4 Comentários

Embarcados Entrevista: Jack Ganssle

Jack Ganssle interview Jack Ganssle

É com muito prazer que trazemos mais uma entrevista, desta vez entrevistamos ninguém menos que o surpreendente Jack Ganssle. Jack, para quem não conhece, é um dos líderes do movimento da qualidade em sistemas embarcados. Nessa entrevista recebemos informações muito sensatas e corretas a respeito do desenvolvimento de sistemas embarcados. Jack mostra que não é necessário grandes mudanças para que se tenha um grande incremento na qualidade do nosso trabalho como engenheiros, e sim que algumas mudanças nos lugares corretos são capazes de gerar incrementos significativos no desempenho das equipes e no número de bugs dos produtos. Por isso Jack nos surpreendeu, mostrando que atingir grandes resultados pode ser simples.

 

A entrevista foi conduzida pelo nosso queridíssimo show man André Prado e o questionário guia, assim como o trabalho de transcrição e tradução, foi efetuado também pelo André Prado, pelo Henrique Rossi, Marcelo Jo, Thiago Lima e por mim. Abaixo seguem as palavras de Jack Ganssle na íntegra e espero que elas sejam tão iluminadoras para os leitores tanto quanto foram para a Equipe Embarcados.

 

André: Por que você escolheu sistemas embarcados?

Jack Ganssle: Esta é uma pergunta interessante, eu meio que caí nisto. Em 1971 eu estava trabalhando como técnico em eletrônica enquanto estudava na universidade. A empresa onde eu estava trabalhando começou a fazer um dos primeiros projetos de sistemas embarcados utilizando o primeiro microprocessador de 8 bits, o 8008, e ninguém sabia nada sobre computadores, então me promoveram a engenheiro pois eu sabia sobre computador. Isto aconteceu há 40 anos e eu nunca saí da área. Para mim é fascinante, pois fazemos o hardware e o software. Eu conheço muita gente fazendo apenas software, e isto é ótimo, mas eu gosto de fazer o software e o hardware.

 

André: Então você também trabalha com hardware, você costuma trabalhar com FPGA e/ou ASIC?

Jack Ganssle: Sim, muito! FPGA é bem comum no mundo dos embarcados e está se tornando cada vez mais. Antes de começar esta entrevista eu estava mexendo com um kit da Xilinx que possui um Zynq, conta com dois processadores Cortex-A9 e mais um monte de recursos de FPGA, é muito divertido.

 

Quando você queria fazer algo customizado, costumava-se construir um ASIC. Mas quem consegue fazer um ASIC hoje em dia? 20nm é algo que custa algumas centenas de milhões de dólares, você consegue um FPGA por 5 dólares. Então, para trabalho de alta velocidade, FPGA é o caminho.

 

André: Quais são os motivos que fazem uma empresa procurar pela sua ajuda?

Jack Ganssle: As empresas estão procurando duas coisas: A primeira e mais importante é fazer seus produtos de forma mais barata e a segunda é ter produtos com maior qualidade. Para a gerência, a ideia de ter as coisas prontas mais rápido é o que os motiva. O engraçado é que, como eu costumo falar nos meus seminários, se você fizer da forma correta será mais barato no longo prazo.

 

Nós temos toneladas de dados que mostram que em um projeto de firmware, metade do tempo é gasto depurando. Isto é uma loucura, eles gastam metade do tempo consertando erros. Nós sabemos que o melhor jeito de fazer um projeto é simplesmente não cometer estes erros em primeiro lugar. Eu vejo desta forma: Se metade do cronograma é debugging, então a outra metade deve ser “bugging”.

 

André: Jack, mesmo nos dias atuais, várias empresas não se importam com qualidade. Eles querem o produto para ontem, o que você pensa disto?

 

Jack Ganssle: Qualidade é algo que me tira do sério, nós não fazemos as coisas que deveríamos fazer para conseguir a qualidade necessária. A Toyota teve que pagar 1,2 bilhão de dólares por causa do seu software ruim, e se você parar para pensar, este código é agora o software mais caro que alguém já escreveu. É verdade que todos temos que ir depressa mas isto sempre vai custar mais caro. Há um ditado que eu gosto bastante “Atalhos fazem caminhos mais longos”.

 

No passado nós nos safávamos pois os sistemas eram bastante simples, mas eles estão muito mais complicados agora. Eu não acho que nós podemos continuar fazendo projetos sem qualidade.

 

E nós sabemos como fazer da maneira certa mas escolhemos não fazer. Para mim é como se fosse um pecado mortal, não é mais aceitável. Nós tivemos 30 anos para nos ensinar a forma correta de construir sistemas embarcados, e mais cedo ou mais tarde, pessoas vão começar a se machucar de verdade com carros sem motorista, sistemas aviônicos e instrumentos médicos.

 

Houve um grande recall nos EUA há alguns anos atrás de bombas de infusão, pois estes equipamentos estavam injetando drogas no sangue devido a erros de firmware.

 

A maioria das empresas em que eu vou, visam qualidade na produção pois eles descobriram que se a produção tiver mais qualidade na hora de montar os equipamentos, eles economizam dinheiro. Mas pouquíssimas aceitaram a qualidade no lado da engenharia, especialmente em firmware. Apesar de que as empresas estão se interessando mais em qualidade pois estão vendo que problemas de qualidade custam - muito - dinheiro. Eu espero que isto mude mas está acontecendo de forma muito lenta.

 

Como você disse, empresas querem o seu projeto pronto agora. E se nós desenvolvermos um milhão de linhas em um mês, logo estarão querendo um milhão de linhas em duas semanas. Em algum ponto isto tem que parar, é insustentável.

 

Eu vejo muita oportunidade para os engenheiros mais novos, eles ainda não foram expostos a décadas de desenvolvimento de forma errada, eu conheço algumas empresas americanas que só contratam engenheiros recém formados para ensiná-los a fazer da forma correta.

 

André: Quais são os maiores obstáculos para se instalar qualidade em uma empresa, talvez convencer a diretoria?

Jack Ganssle: É verdade que podemos colocar a culpa na diretoria, mas acho que muitas vezes nós engenheiros apontamos o dedo para a direção, quando deveríamos apontar para nós mesmos. Diversas vezes nós ficamos com vontade de pegar atalhos, porque escrever código é legal, debuggar é legal também, mas sentar e fazer e atender os requisitos corretamente, para muitas pessoas, é muito difícil. Então nós pulamos essa fase e vamos direto para o código. É como ir a uma loja de máquinas e perguntar ao lojista “Eu quero que construa uma máquina pra mim”, sem lhe oferecer nenhum plano. Ele começará a furar em peças de metal e isso vai fazer com que ele leve uma eternidade até que termine o trabalho. Mas se, ao invés disso, lhe entregar planos detalhados e corretos, ele vai fazer o trabalho no tempo adequado. É aí onde a criatividade realmente está, no design, e, para mim, tenho muito mais satisfação com o design. Então posso entregá-lo ao pessoal para que o implementem.

 

André: Você se concentra em processos como o “TDD” ou o “agile” ?

Jack Ganssle: Sim, eu foco em processos, mas não sou um fã de TDD. Quando eu vejo sendo usado é quase hacking. Pessoas escrevendo código o mais rápido possível sem ter certeza que o design está correto. Como você tem certeza que os testes estão certos? Você conhece James Grenning? Ele é um dos caras que assinou o Agile Manifesto. Ele ensina TDD no mundo de embarcados e é um grande homem, um amigão, mas nós não concordamos nesse assunto. Temos muita discussão agradável sobre o tema. Eu acho que o pessoal de Agile acerta em muitas coisas, o foco no processo em espiral está certo e eles realmente acreditam em testes extensivos, o que é muito importante. Então, eles falam de muitas coisas boas, mas frequentemente deixam o design a desejar, que é um problema que tende a aumentar principalmente quando os sistemas tendem a se tornar cada vez mais complicados. Então, sim, eu falo sobre questões de processos sem pensar em termos de processos pesados, mas mais sobre como o que podemos fazer numa forma espiral pra desenvolver um produto. Eu falo sobre métricas. Você sabe, nós engenheiros trabalhamos com números. Mas se você perguntar a um desenvolvedor de firmware sobre qualquer tipo de métrica, dificilmente terá uma resposta. Por exemplo, “qual é a taxa de bug?”. Isso é uma informação crítica que você pode medir de uma infinidade de maneiras, mas a maioria das pessoas não sabe o que são esses números. “Qual é o tempo de resposta real se você estiver escrevendo uma rotina de interrupção?”. Em outras palavras, ele executa em um microssegundo, um milissegundo ou em uma semana? As pessoas não sabem. Eu acho isso um problema importante a notar, ainda que métricas são fáceis de se calcular. Como engenheiro você projeta algo, você prevê o que acontecerá, você implementa e mede o que foi feito para ter certeza de que o que está acontecendo bate com o que foi previsto. Em caso contrário, aí você terá que se perguntar coisas do tipo: “Por que estão diferentes?”, “Tenho algum erro de projeto? Cometi algum erro?”

 

André: Então você não concorda com o movimento “Agile”? Está na moda dizer “Eu faço Agile”.

Jack Ganssle: Existem várias modinhas no campo de software. Sempre há uma modinha, quase todas elas tiveram excelentes coisas a dizer e melhoraram nosso conhecimento. Agile tem ideias fantásticas, é algo incrível que aconteceu para a engenharia de software, mas, quase toda empresa em que eu vou, dizem que fazem Agile para encobrir o Caos que é a empresa. Eles dizem: “Nós fazemos Agile, você não pode nos perguntar sobre cronograma”. Fazer Agile de forma correta necessita de muita disciplina e poucas empresas o fazem.

 

André: Quais os tipos de métricas você considera em um time?

Jack Ganssle: Há várias, nós podemos falar de algumas. Eu acho que é critíco saber quantos bugs você injetou no sistema e qual a porcentagem desses bugs que foi removida antes do sistema ser vendido. Nós esperamos que seja 100%, mas provavelmente não é. Existem artigos que mostram o que locais com alta disciplina fazem e o que péssimas empresas fazem. Se você não sabe onde você está, você não sabe se está fazendo do jeito correto ou do jeito errado. Há um ditado que diz: “Você gerencia o que você mede”, se você não medir bugs, você não vai gerenciar bugs. Há dados interessantes que mostram que se você medir só estas duas coisas, você consegue uma ordem de magnitude de redução de bugs em 1 a 2 anos. Eu também acredito em medir tudo relacionado a tempo real, muitas pessoas dizem que é dificil, e pode ser que seja, mas com um osciloscópio e outras ferramentas você consegue os dados de forma fácil. Se você não tiver este tipo de informação, nós não sabemos onde estamos.

 

André: Você pode nos contar um caso de muito sucesso e um de fracasso em sistemas embarcados?

Jack Ganssle: Vou te contar o caso de maior sucesso de projeto embarcado feito até hoje, o ônibus espacial. A média é de um bug a cada 400 mil linhas de código. Isso é incrível, eles fizeram um trabalho fantástico. Outro projeto chamado Tokeneer, um projeto governamental que foi feito numa linguagem chamada Spark (Spark é um subconjunto de Ada com algumas extensões de checagem). Eles tiveram um bug, somente um bug em todo o projeto. Vi um projeto de um avião militar feito em Spark, eles passaram todos os testes de checagem e corrigiram tudo o que foi encontrado. Quando foi finalizado, não havia um bug, nunca encontraram nada. Conheço pessoas que usam Spark que esqueceram de como usar um depurador. A maioria de nós não chegará nesse ponto, mas podemos melhorar muito de onde estamos. Projetos embarcados médios possuem uma taxa de erro de 5% a 10% depois de uma compilação limpa, então se você escreveu 1000 linhas de código, terão 50 a 100 bugs nele. É muita coisa! Para reduzir isso em uma ordem de magnitude não é assim tão difícil. Sabemos que temos que usar padrões para escrever o código, fazer inspeções e seguir boas práticas. Mas a maioria de nós não quer ser incomodada. Com certeza os gerentes têm a sua culpa, assim como nós.

 

André: E sobre casos de fracassos?

Jack Ganssle: Existem tantos pra se escolher… Tem o Therac 25, uma máquina para matar células cancerosas por radiação nos tumores. Na verdade ele matou várias pessoas por problemas de software. Outra máquina parecida no Panamá, há 10 anos, que matou 21 pessoas por causa de problemas de software. É muito triste. Se você vasculhar o código pra ver o que aconteceu nesses casos, verá que era um caos puro. Ninguém sabia o que tinha no código, não havia nenhuma especificação real, pouca documentação. Eles quebraram todas as regras óbvias, e como resultado pessoas morreram. Houve um caso onde os ingleses fizeram um projeto para um helicóptero e após um acidente onde 25 pessoas morreram, eles revisaram o código. O código era tão ruim que eles desistiram após terem revisado apenas 17%. Essa é a minha mensagem: Nós sabemos como fazer corretamente sistemas embarcados, e se formos profissionais disciplinados, precisamos adotar melhores práticas. Eu acredito muito que todos nós conseguiremos seguir essas boas práticas, só que isso vai levar um tempo.

 

André: Você acha que novas metodologias aparecerão ou o que temos hoje é suficiente?

Jack Ganssle: Este é um campo interessante pois sempre tem coisa nova acontecendo. Uma das coisas que eu mais gosto é estudar e ficar por dentro do que está acontecendo de mais novo. Então, novos conceitos e processos estão aparecendo toda hora, mas eu acho que, para ganhos imediatos, nós não precisamos de nada novo. Só precisamos adotar o que já sabemos há anos. Alguns dizem que não conseguiremos uma solução 100% perfeita com o que temos - e eles têm razão - mas nós podemos conseguir 90%, o que é uma nota A. Muito melhor do que os Cs e Ds que temos agora.

 

André: O que você acha do movimento maker? Sobre os kits Raspberry Pi, BeagleBone e Arduinos?

Jack Ganssle: Eu tenho uma Raspberry Pi comigo aqui. Eu tenho sentimentos mistos sobre o movimento maker. É a melhor coisa e a pior coisa. É a melhor coisa pois esses produtos fazem as pessoas se interessarem por tecnologia. Como engenheiro, eu me sinto frustrado quando as pessoas não se interessam pelo funcionamento das coisas. O movimento maker tem colocado várias pessoas de fora da área de tecnologia em contato com tecnologia e isto é fantástico. Meu medo é de que pessoas com pouco conhecimento pensem que são engenheiros. É fácil fazer luzes piscarem e outras coisas legais, mas para fazer um produto de verdade, que vai de algumas centenas de linhas de código para milhares de centenas, é algo muito mais difícil. A imprensa dos EUA diz que temos um novo Albert Einstein toda vez que um rapaz de 16 anos faz algo com um Arduino. Eu admiro essa criança e espero que ela faça mais coisas legais, mas eu realmente torço para que ela vá para a universidade e consiga um diploma de engenheiro para virar um profissional.

 

André: Como você vê o campo de sistemas embarcados no Brasil?

Jack Ganssle: Eu acho que está crescendo, eu conheço várias empresas que estão indo para o Brasil. Todos os vendedores de semicondutores estão no Brasil e eles dizem que conseguem bons engenheiros por muito menos dinheiro do que nos EUA. Os engenheiros são bons, o horário é parecido com o dos EUA e muitas pessoas falam inglês.

 

André: O que você acha da tendência de exportar projetos para países de terceiro mundo, como o Brasil, Índia e outros? Você acha que os EUA vão sofrer com isto ou é apenas algo esperado para maximizar os lucros?

Jack Ganssle: Eu acho que é tudo isto. Empresas querem maximizar o lucro, mas elas também fazem isto pois precisam de recursos de engenharia. Há bastante debate nos EUA sobre se há ou não falta de engenheiros por aqui, mas o fato é que temos muito emprego. Há bem poucos engenheiros sem emprego. Eu passei toda a minha vida viajando pelo mundo e encontrando grandes desenvolvedores em todos os lugares. Há milhões de pessoas terceirizando para a Índia, por exemplo. Parece que as empresas mais bem sucedidas têm uma divisão própria de operação por lá, e desse jeito eles podem moldar a direção dos seus projetos. No Brasil é um pouco diferente, pois, como você disse, a indústria é pequena. Mas a Índia é como o Brasil em outra questão também, os engenheiros são jovens e bem entusiasmados, o que é sensacional. Eu acho que de um modo geral, outsourcing vai ser algo bom para o mundo. Em alguns países é o jeito de sair da miséria e isto é maravilhoso.

 

André: E a qualidade destes projetos feitos em países de terceiro mundo?

Jack Ganssle: Eu diria que é tudo a mesma coisa, feito nos EUA ou em qualquer outro lugar. Não importa de onde vem. Porém, no último verão eu estava na República Tcheca e existia um projeto com milhões de linhas e todos os comentários em Tcheco. Existem apenas dez milhões de pessoas no mundo que falam Tcheco, então eles têm um problema real! Todo o código deveria ser documentado em inglês.

 

André: Bem, vamos falar sobre a sua visão do futuro, como você vê a área de sistemas embarcados em 2020?

Jack Ganssle: Bem, o que eu tenho visto na minha carreira é que quando você projeta 10 anos no futuro, você projeta todo o tipo de coisa, mas quando você chega lá, o que aconteceu é algo que você nunca tinha sonhado. Por exemplo, smartphones. Dez anos atrás ninguém teria imaginado que você teria a internet no seu bolso, ou um GPS. Quando eu era mais novo era ilegal ter um telefone nos EUA. Agora todo mundo tem esses aparelhos fantásticos no seu bolso, então eu acho que previsões são difíceis. Mas eu penso que é bastante claro que a lei de Moore vai continuar pelos próximos 8 a 10 anos, o que significa que em 10 anos, ao invés de termos smartphones com 100 bilhões de transistores, teremos trilhões de transistores. E isto será um smartphone bem inteligente.

 

A robótica será mais importante do que as pessoas conseguem entender hoje. Nós não estamos tão longe disto. A tecnologia de baterias está ficando melhor o tempo todo. A mecânica estão ficando melhor e a eletrônica está onde precisa estar para fazer robôs bem inteligentes. E, se você pensar, robôs poderão produzir robôs e robôs serão utilizados para fazer o trabalho sujo, como mineração. Eu me preocupo se o valor do trabalho vá para zero pois os robôs farão todo o trabalho. Engenheiros estarão em uma ótima posição mas tenho medo pelas outras pessoas. Por exemplo, com os carros autônomos do Google, o que acontecerá com os taxistas quando não precisarmos mais deles? Então eu acho que iremos descobrir que a tecnologia continuará a evoluir mas teremos problemas sociais seríssimos como resultado disto. E eu não sei o que acontecerá em relação a isto.

 

André: Como você vê a qualidade nesta visão??

Jack Ganssle: Bem, se você tem milhões de carros dirigindo de forma autônoma pela cidade, a qualidade tem que ser boa. Quando eu vou ao Brasil, eu normalmente vou para São Paulo, e tudo que eu posso dizer é que os carros não se movem muito rápido por lá! Mas é interessante que carros autônomos se comuniquem, então você vai ter uma rede extremamente complicada. Olhe no setor de aviação, nós sabemos como fazer sistemas complexos funcionarem, poderemos usar as lições aprendidas no projeto de produtos aviônicos e outras aplicações onde a segurança é critica. Existem produtos incríveis hoje que ajudarão, como o sistema operacional de tempo real Greenhills, por exemplo, que foi provado ser matematicamente perfeito.

 

André: E os drones?

Jack Ganssle: Drones são muito interessantes, a tecnologia necessária já está no mercado. Funciona. Mas estão aparecendo diversos problemas legais, por exemplo: Você pode pilotar seu drone em cima da propriedade do seu vizinho? Você pode tirar fotos da janela do seu vizinho? É assustador, estamos começando a vê-los e muitos problemas legais precisam ser resolvidos. A Amazon está querendo entregar encomendas com drones, e eu acho que eles são loucos. A energia necessária para usar um drone é muito alta quando comparada a um caminhão que entrega para 500 casas na vizinhança. A conta não fecha. Mas para diversas outras aplicações nós vamos ver muitos drones por aí, será interessante ver o que vai acontecer com o espaço aéreo.

 

André: E o que você acha da Internet das coisas (IoT) ?

Jack Ganssle: Quando eu ouço o termo IoT eu tenho vontade de vomitar. É só uma sigla de marketing. Nós temos feito a internet das coisas por 20 anos. Estamos coletando dados via internet há anos. Então isto é só uma nova palavra que as pessoas do marketing têm utilizado, mas o fato é que, por causa de algumas novas tecnologias, como o ARM Cortex-M0, você pode comprar um processador de 32 bits por 50 centavos de dólar. A maioria tem Ethernet e Wi-Fi na placa, então vamos ver muito mais coisas conectadas à Internet. Está ficando cada vez mais fácil, podemos pegar stacks TCPs open source e utilizar nos nossos microcontroladores. E isto é outra coisa interessante, muitos destes microcontroladores não consomem quase nenhuma energia. Eles podem rodar com o consumo de miliamperes, e então você pode conseguir energia de todos os tipos de lugares. Power Harvesting vai ser uma grande área, baterias são relativamente caras e precisam de recarga. Para muitas aplicações energy harvesting vai ser o caminho a seguir. Supercapacitores estão tão bons que se tornou fácil coletar energia e carregar um supercap. Vão haver sensores por todos os lugares, conectados a uma rede mesh que irá se conectar por Wifi ou GPRS a estas coisas. Haverá problemas sociais também, como na parte de robótica. Mas eu acho que sensores inteligentes trarão muitos benefícios.

 

André: O que você acha da tecnologias legadas, como microcontroladores de 8 e 16 bits?

Jack Ganssle: Bem, é complicado. Você sabe, e se você pudesse construir um sistema por um centavo? Então, talvez, exista um mercado interessante para 8 bits. Estes processadores são feitos de uma tecnologia obsoleta, como 250 ou 180 nm, todas estas fabricas já se pagaram. Se você for fazer algo em 45 nm, ainda há alguns bilhões de dólares que devem ser amortizados nos preços dos produtos. E com ARM há sempre as taxas, pois você deve pagar para os proprietários da ARM uma taxa cada vez que você vende um microprocessador. Então, 8 bits sempre vão ser mais baratos. Há com certeza uma grande tendência para 32 bits, não há dúvidas, e 32 bits pegarão cada vez mais pedaços do mercado, exceto pequenos nichos onde o custo e o consumo importam mais do que todo o resto. Alguns vendedores de 8 bits me dizem que ainda possuem um bom mercado pois muitos dos seus usuários não são desenvolvedores de firmware. Eles querem apenas escrever algumas centenas de código em C e não querem algo complicado. Isto é interessante também, ARMs possuem uma complexidade para IO que algumas pessoas não querem aprender.

 

André: Você acha que o futuro é 100% ARM?

Jack Ganssle: Eu acho que o futuro próximo é ARM. A Intel quer entrar no espaço de sistemas embarcados. Eles têm errado um pouco mas possuem uma equipe muito inteligente, eventualmente vão acertar. Mas para os próximos cinco anos, a participação da ARM vai ser de provavelmente 60% a 70% do mercado.

Após isto, quem sabe? Tenho certeza que uma nova invenção que nós nem imaginamos ainda possa aparecer.

 

André: O que você acha sobre o uso de FPGA na indústria? Algumas pesquisas têm mostrado que o uso de FPGA tem diminuído nos últimos anos, enquanto a intenção de utilizá-los tem crescido.

Jack Ganssle: Eu participei da construção de algum desses estudos, e eu acho que as questões são colocadas de forma errada. Se você ver os dados destas pesquisas... Você simplesmente não pode confiar neles. Você vai ter alguém dizendo “Eu sou um engenheiro de firmware, não trabalho com hardware mas projeto em FPGAs”. As vezes as respostas não fazem sentido. O mercado de FPGAs tem crescido, Xilinx e Altera estão maiores a cada ano. Eu acho que o uso de FPGA definitivamente está crescendo. Existe um produto da Xilinx que está sendo utilizado em carros para interfacear com câmeras, verificar o tráfego, ver se o carro está saindo da pista e etc. isto é muito difícil de fazer com software. Processamento de imagem é complicado pois a quantidade de dados é muito grande, mas para FPGA é natural. E o que eu tenho observado é que a taxa de dados sobe todos os anos. Eu comprei uma câmera digital com um sensor de 20 megapixel. A quantidade de dados vindo desta câmera é muito alta. Processadores sempre ficam mais rápidos mas são limitados pela memória e a memória não tem ficado mais rápida nos últimos anos. Então não importa quão rápido é seu processador, o gargalo é a memória. FPGAs podem fazer muita coisa em hardware e de forma muito rápida, estou otimista quanto a este mercado.

 

André: E sua experiência no Brasil, você já teve a oportunidade de prestar consultorias por aqui?

Jack Ganssle: A primeira vez que eu estive no Brasil a trabalho foi em 1978, eu estive por um mês trabalhando em diversas máquinas. Estive em Porto Alegre, São Paulo e na floresta. Foi uma época fantástica. Hoje em dia minhas viagens são bem curtas, apenas alguns dias para falar em seminários, ou uma pequena consultoria de 1 a 2 dias. Eu não sou um fã de São Paulo pois o trânsito é brutal, mas o resto do Brasil é fantástico. Eu amo o povo, é bem divertido e simpático. Caipirinha é uma das razões que me fazem estar desapontado de não ir na ESC neste ano.

 

André: Que conselho você daria para nós engenheiros de sistemas embarcados?

Jack Ganssle: Bem, está é uma ótima questão. Eu sempre falo para os engenheiros jovens que a primeira coisa que eles devem fazer é guardar dinheiro. Guarde um pouco de dinheiro de cada pagamento, você vai ficar velho mais rápido do que você pode imaginar e alguém com dinheiro no banco tem opções. Se você não tiver dinheiro no banco, você vai precisar se sacrificar para ter um trabalho. A segunda dica é para se interessar pelo seu campo de atuação, sempre continue aprendendo. Esta é uma área legal e sempre tem muita coisa interessante acontecendo, mas eu vejo muitos engenheiros que param de aprender coisas novas quando se formam na universidade. Se você quiser ficar nessa área, você vai precisar estudar pelo resto de sua carreira. E outra coisa que eu tenho a dizer, foi um conselho dado a mim por um amigo há muitos anos: você tem que fazer dinheiro e você tem que se divertir. Se você tem somente um dos dois, não é suficiente. Muitas vezes pensamos só no dinheiro mas se você tem que fazer algo por 40 anos, é bom que você se divirta fazendo e coloque um sorriso no rosto todas as manhãs.

 

André: Você ainda se diverte codificando ou prefere projetar?

Jack Ganssle: Eu não codifico muito mais, apesar de estar fazendo isto quando você me ligou. Eu acho bem mais divertido olhar a arquitetura do sistema. Eu não dou consultoria da maneira que as pessoas imaginam, mas frequentemente dou dicas arquiteturais para os produtos das empresas. Ocasionalmente eu vou e resolvo um problema para uma empresa, pois gosto de estar do lado de hardware e software dos projetos. Eu estava trabalhando na Suécia por alguns dias uns meses atrás, eles tinham um problema de timing de 50 ps, foi muito interessante solucionar este problema. Mas eu não gosto mais de sentar e escrever centenas de milhares de linhas de código.

 

André: O que você espera do seu trabalho nos próximos anos?

Jack Ganssle: Algumas vezes minha esposa diz que eu devo me aposentar, mas estou me divertindo muito ainda! Você sabe, eu não tenho um emprego de verdade. Dou palestras, um pouco de consultoria e outras pequenas coisas, escrevo bastante. Tenho muita liberdade e eu adoro isto. Eu também faço meus projetos próprios e experimentos, ultimamente tenho feito experimentos com o comportamento de baterias em sistemas de consumo ultra baixo, apenas por curiosidade. Eu espero fazer isto por pelo menos mais dez anos, quem sabe.

 

Licença Creative Commons Esta obra está licenciada com uma Licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional.

Receba os melhores conteúdos sobre sistemas eletrônicos embarcados, dicas, tutoriais e promoções.

Entrevistas » Embarcados Entrevista: Jack Ganssle
Talvez você goste:
Comentários:
recentes antigos mais votados
Notificar
trackback

[…] o prazer de entrevistar Clive "Max" Maxfield [7], Jack Ganssle [8] e Sergio Prado […]

trackback

[…] excelente livro de Jack Ganssle, The Art of Designing Embedded System Design, são apresentadas ao leitor boas práticas para o […]

Marlon Luft
Visitante
Marlon Luft

O Jack Ganssle é um dos mais renomados profissionais da atualidade, tive a honra de prestigiar algumas apresentações dele no Brasil e nos USA, todas foram fantásticas, nos últimos três anos do ESC Brazil nós contamos com a participação do Jack no evento, este ano estamos trazendo outras atrações para o evento como o Jon "maddog" Hall, um dos precursores do Linux.

Emiliano Veiga
Visitante
Emiliano

muito bom! Parabéns pela entrevista pessoal!

Séries

Menu