Índice de dor de cabeça em projetos de software

Um novo projeto de software é iniciado. Os gestores do projeto começam os rituais de levantamento de requisitos, modelagem e estimativas de custos e prazos. O foco é colocar esse software no ar, sua concepção é o projeto, é o objeto do contrato, é o que está sendo vendido e que vai ser listado em sua lista de conquistas em sua página do LinkedIn.

Mas a experiência na área de tecnologia nos mostra que o que vem depois é que mede de verdade o sucesso desse projeto. Manutenção é uma palavra que não inspira desenvolvedores, ninguém tatua essa palavra no próprio corpo, ninguém faz filmes de ficção científica sobre o tema, mas é uma das principais razões para existirem engenheiros de software profissionais.

Escrever código que funciona é fácil. É algo que qualquer um consegue fazer, basta paciência para aprender usando tutoriais, livros ou professores. Mas o profissional precisa sempre levar em consideração que amanhã alguém vai precisar alterar esse código e algum usuário pode ter um prejuízo se algo não estiver funcionando corretamente. Fazer funcionar é fácil, é a parte do trabalho que é uma ciência exata. Construir algo que é possível de manter funcionando é mais próximo de uma arte, um misto de experiência, intuição e criatividade.

Pensar nos custos de manutenção se torna ainda mais crítico quando você não tem uma equipe grande de desenvolvedores. A maioria das tarefas de manutenção não são possíveis de prever e quanto menos braços a disposição, menor o número de coisas que podem ser feitas em paralelo. Trabalhando sozinho, pode ser que você precise assistir sua cozinha pegando fogo enquanto você tenta apagar o incêndio no seu quarto.

Esses eventos não previstos que geram a necessidade de alteração do código de seu software é o que chamo de “dores de cabeça”. Quando uma dor de cabeça surge, as tarefas que você havia planejado precisam ser adiadas, talvez você precise trabalhar em finais de semana e madrugadas e em alguns casos até cancelar compromissos. Elas existem em todos os projetos, mas existem características que tornam um projeto mais suscetível a alguns tipos de dor de cabeça.

Batman, cancele as férias que deu ruim aqui!

Para tentar entender melhor a quantidade de trabalho que podemos ter com a manutenção de um software no futuro, nós precisamos de um índice de dor de cabeça. Com esse índice, podemos analisar pelas características de nosso projeto, quais tipos de dor de cabeça vão afetar nossas noites de insônia. E é claro que isso não pode ser algo exato, com uma fórmula que vai cuspir um número que você pode usar em uma planilha de custos, mas ele pode te ajudar a decidir quais tipos de problema você está disposto a encarar baseado nas decisões de projeto hoje.

Mais funcionalidades = mais dor de cabeça

Este é o fator básico e mais óbvio deste índice. Quanto mais coisas seu software faz, maiores as chances de algo precisar de manutenção.

Seu software vai ter funcionalidades fechadas, como por exemplo funções que calculam algo sem nenhuma interação com atores externos e que portanto são fáceis de testar. Essas provavelmente não vão gerar muita dor de cabeça, a não ser por bug que ocorrem em casos que não foram pensados durante os testes.

Quando você tem funcionalidades em que partes de seu sistema dependem de outras partes do seu sistema, a chance de existirem esses casos de exceção que não foram pensados começa a aumentar. Uma dessas partes pode ser alterada e a interação entre as duas mudar de forma que novos bugs surjam.

Por isso, quando um usuário te pede para implementar algo que parece ser muito fácil, você sempre precisa se lembrar que isso pode virar uma bola de neve de dor de cabeça.

Cada funcionalidade de seu software deve aumentar 1 ponto em seu índice de dor de cabeça.

Bibliotecas e dependências

Uma das vantagens do ofício de desenvolvedor de software é que você pode reutilizar o trabalho de outros desenvolvedores. A cada novo projeto não precisamos criar do zero os sistemas operacionais, bancos de dados, bibliotecas e outros sistemas utilizados em nossa solução.

O problema é que você não tem controle sobre essas dependências por serem mantidas por outras empresas ou desenvolvedores de open source. E isso significa que a manutenção dessas partes do sistema mudam sem seu controle e podem gerar bugs em seu sistema. E é por isso que precisamos ter cuidado ao atualizar nossas dependências.

O que nos impede de usar para sempre as mesmas versões de bibliotecas que sabemos que funcionam? O motivo mais forte é que muitas vezes essas dependências são atualizadas porque uma brecha de segurança foi descoberta. E o outro motivo é que nossas dependências tem suas próprias dependências que podem afetar outras dependências de seu software quando você for forçado a atualizá-las.

Esses dois motivos nos forçam a acompanhar as versões atuais das dependências para manter nossas bibliotecas em versões próximas às versões mais atuais. Atualizar de uma versão para a seguinte já é complicado, mas quando você descobre que precisa fazer o upgrade de algo que está na versão 2 em seu sistema para a versão 10.0 na versão mais atual, comece a rezar.

Cada dependência de seu software deve aumentar em 2 pontos seu índice de dor de cabeça. Cada ponto de versão em que você está defasado em relação à versão mais atual de uma dependência, multiplique esses pontos por 5.

Integrações com outros sistemas

Assim como bibliotecas, integrar com outros sistemas nos poupa de ter que construir tudo que precisamos para que um sistema funcione. E assim como bibliotecas, APIs externas afetam nossos sistemas quando sofrem alterações ou apresentam algum problema.

A diferença é que nós podemos segurar um pouco atualizações de bibliotecas e continuar com as versões que estão funcionando até termos tempo para trabalhar nisso. Já mudanças em APIs têm um prazo para acontecer, e talvez você não tenha a opção de esperar. Ou não receba os avisos de que a API vai mudar. Ou simplesmente esteve tão ocupado que acabe esquecendo e só sendo lembrado quando algo no seu sistema para de funcionar.

Em alguns casos você precisa lidar com mudanças de comportamento de uma API que não aconteciam quando a integração foi feita. Pode ter sido alguma mudança que os desenvolvedores da API acharam que não iam causar muito impacto ou simplesmente alguns erros que você nunca havia visto começam a acontecer porque o sistema da API tem novos bugs ou não está escalando para a carga atual.

E ainda existe o maior problema que são APIs desativadas. Empresas desistem de projetos ou vão à falência e você vai ter que correr para pesquisar, testar alternativas e talvez tenha que construir as mesmas funcionalidades do zero.

Cada ponto diferente de seu código que faz uma chamada para uma API externa deve aumentar 50 pontos em seu índice de dor de cabeça. (Largue a planilha, eu disse que esses números não significam nada).

Legislação

Mudanças em leis podem afetar seu software. Podem ser exigências de como ele deve se comportar, (exemplo: leis de proteção à privacidade na internet). Ou podem afetar os dados utilizados, que vão desde a forma como impostos são calculados até a modelagem de dados (imagine se você tiver tabelas de cônjuges e de repente a poligamia é liberada por lei em seu país).

Essas mudanças nem sempre oferecem um prazo razoável, já que os legisladores não tem como prioridade estimar o quanto cada lei pode afetar sistemas que dependem dessa lei.

Para cada ponto em seu código em que existe um cálculo baseado em lei, adicione 100 pontos ao seu índice de dor de cabeça. Se seu software é usado em alguma área em que a legislação muda muito, adicione mais um número bem grande. Multiplique esse número grande pelo número de páginas da legislação.

O objetivo do índice não é que você procure pela dor de cabeça zero. Um sistema com índice zero com certeza é simples demais e não muito útil. A análise pelo índice serve apenas para que possamos entender os trade-offs que as decisões tomadas na concepção do software podem ter no decorrer de sua vida.

Além disso, a dor de cabeça de uma pessoa pode ser a oportunidade de outra. Você pode oferecer uma solução para algo que os outros consideram uma dor de cabeça. Ou simplesmente oferecer a terceirização da dor de cabeça, para que os outros possam se focar em questões mais centrais a seus negócios.

Camadas de bolo e apps mobile usando javascript e Titanium Appcelerator

Um aviso para que você não perca seu tempo: isto não é um tutorial de Appcelerator, apenas reflexões sobre este tipo de ferramenta baseadas em minha experiência com Titanium Appcelerator. Talvez te ajude a decidir o que usar para desenvolver apps para smartphones e tablets. Ou talvez só te deixe com um pouco de fome, dependendo do horário.

A área de tecnologia se move em saltos muito maiores que outras áreas porque nós usamos muito bem o poder da abstração. Quando uma tarefa é muito complicada de se fazer conseguimos criar uma interface mais simples para essa tarefa, escondendo toda a complicação. Com a complicação escondida em um nível de abstração, essa tarefa pode ser usada como componente de outras tarefas sem que seja necessário pensar muito em seus detalhes.

Isso pode ser observado no desenvolvimento de software com Java, por exemplo. O código Java é um nível de abstração e vai ser compilado para bytecode. O bytecode vai ser rodado por uma máquina virtual que foi escrita e C/C++ e é outro nível de abstração. E o computador executa essa máquina virtual como linguagem de máquina, outro nível de abstração. Esse exemplo poderia ser dividido em vários outros níveis, mas a ideia está aí: cada nível de abstração esconde detalhes para tornar o trabalho de outro nível mais fácil.

Essa é a teoria. Mas muitas vezes um desses níveis de abstração pode não tornar o trabalho mais fácil, ainda mais porque “fácil” é um conceito subjetivo e que depende de contexto. E cada nível aumenta a probabilidade de algo dar errado, porque um erro em um nível mais baixo de abstração vai se propagar para os níveis mais altos. Por isso o valor de usar níveis de abstração não vai necessariamente aumentando a cada nível e por isso não tentamos criar deliberadamente milhões ou infinitos níveis para que o trabalho se torne infinitamente mais fácil.

Eu penso nisso como um bolo com várias coberturas. Na teoria um nível de cobertura deveria tornar o bolo mais gostoso, mais fácil de engolir, mais agradável visualmente. Mas às vezes alguém vai colocar uma camada de chocolate amargo com cacos de vidro e eu não gosto muito de chocolate amargo.

hmmmmmmmmmmm

Alguns anos atrás estávamos precisando desenvolver apps para iPhone e Android para o Arivo. Como não conheço muito de desenvolvimento para iOS e Android, procurei por soluções que nos ajudassem a acelerar isso, já que precisava ficar mais focado na aplicação web que é a parte principal do Arivo.

Contratar uma agência era uma possibilidade. É um pouco caro demais para o que precisávamos, mas o motivo para não termos escolhido esse caminho não foi financeiro. Nossa aplicação ainda estava mudando muito, o que ia gerar muitas mudanças nas apps e era importante ter mais flexibilidade do que teríamos se contratássemos terceiros para isso. É claro que uma agência iria atender as mudanças no meio do caminho, mas isso ia custar tempo, dinheiro e stress.

Por isso procurei por ferramentas que tornassem esse desenvolvimento mais fácil, ou seja, procurei por algo que me desse um nível de abstração. Além do problema de não conhecer as plataformas iOS e Android, desenvolver para duas plataformas diferentes tomaria muito tempo e esforço. Precisava de algo que me ajudasse a programar apps para as duas plataformas sem ter o trabalho duas vezes.

Existem várias opções no mercado e os critérios que usei, do mais importante para o menos importante:

• Gerar apps para iOS e Android.
• Gerar apps nativas. Muitas dessas ferramentas geram apps em HTML5, que na verdade são páginas HTML imitando alguns controles da plataforma, mas que muitas vezes não funcionam exatamente da mesma forma.
• Usar alguma linguagem de programação que eu conheça bem.
• Não ter um custo muito alto.

Pesquisei várias opções, como Sencha, RubyMotion, Xamarin, PhoneGap e acabei escolhendo o Titanium Appcelerator. O Appcelerator gera aplicações nativas e usa javascript como linguagem de programação. Pode ser usado gratuitamente mas também tem opções pagas com mais serviços.

No começo, usar o Appcelerator parece um sonho. Criar apps usando javascript ao invés de Objective C e Java sem precisar aprender duas APIs. Rodar as apps nos simuladores, ou em smartphones de verdade, ou gerar os arquivos para envio para a App Store só apertando um botão na IDE. Conseguir desenvolver funcionalidades muito rápido. É a parte doce dessa camada do bolo.

Mas não demora muito para encontrar os cacos de vidro nessa camada.

O primeiro problema é mais uma consequência de gerar apps nativas do que algo causado pela ferramenta. As duas plataformas, iOS e Android tem diferenças de como se comportam e de padrões de interface. Por isso, em alguns casos você tem elementos que se espera aparecerem em uma posição e com um visual que é diferente entre as duas plataformas. O Appcelerator não consegue cuidar automaticamente de todos os casos, então muitas vezes eu preciso enfiar um condicional, um “if (system == ‘android’)” para acertar o resultado final. Poderia uniformizar e ter menos trabalho, mas achava importante respeitar o padrão.

Com o passar do tempo e ao tentar utilizar novas versões é que você começa a encontrar os cacos de vidro maiores e que descem rasgando sua garganta por dentro. Algumas coisas funcionam diferente de uma versão para outra, sem nenhuma documentação sobre essa mudança de comportamento. Você começa a encontrar bugs que foram reportados no fórum do produto e que não foram resolvidos por muitos anos. E você precisa dar um jeito das apps continuarem funcionando para seus clientes, o que significa muita tentativa e erro até conseguir adivinhar como dar uma volta nesses problemas.

Também existem alguns problemas de performance, mas são menores do que esperava de algo que roda javascript. Em celulares de modelos mais antigos a app fica muito lenta a ponto de se tornar um problema de usabilidade. Mas nos atuais funcionam muito bem.

O que é uma pena porque é um produto com muito potencial, e provavelmente se a empresa investisse em qualidade conseguiria resolver todos os problemas. Agora que a Appcelerator foi comparada pela Axway, talvez isso mude, mas eu não vou ficar esperando. No Arivo planejamos criar uma nova versão das apps, provavelmente com uma camada a menos de abstração, mesmo que isso acabe duplicando o trabalho, porque provavelmente muitos dos problemas do Titanium vão ser encontrados nos concorrentes.

Isso é agravado pelo fato de que as próprias plataformas mudam bastante. A cada versão de iOS e Android surgem mudanças e esse tipo de ferramenta que cria um nível a mais de abstração leva um tempo para se adequar e alcançar essas mudanças, ou simplesmente não implementam algumas delas.

No fim diria que não foi um erro usar Titanium Appcelerator, porque ele realmente ajudou com o objetivo de poupar trabalho e lançar rapidamente apps para o Arivo. Mas não recomendaria o uso de uma ferramenta como essa a não ser que a app seja realmente bem simples ou se como nós você tiver a opção de refazer tudo do zero no futuro.

Matem o formato CSV

Se você trabalha com dados já deve ter usado um arquvo CSV. Quase todo programa tem alguma forma de importar ou exportar dados nesse formato, quase como se fosse um padrão.

O arquivo CSV é só um arquivo de texto, em que cada linha contém dados de um registro e cada campo de um registro em uma linha é separado por um caracter separador.

"Nome","Instrumento"
"John Lennon","Guitarra"
"Paul McCartney","Baixo"
"Ringo Stars","Bateria"
"George Harrison","Guitarra"

O formato tem muitas vantagens que o tornaram popular desde os primeiros softwares de planilha eletrônica. É tão simples que um ser humano consegue ler e escrever um CSV usando um editor de texto simples. É fácil de implementar e por isso todo sistema tem alguma forma de importar e exportar dados nesse formato.

Mas é um formato que fazia mais sentido quando não existiam redes e por isso não se trocavam tantos arquivos entre computadores diferentes, sistemas operacionais diferentes e softwares diferentes com configurações regionais diferentes. O arquivo CSV di jeito que existe hoje devia morrer de velho ou ser sacrificado, se isso fosse possível.

O maior problema do formato CSV é a forma como ele lida com encodings. Ele não lida. O programa que lê o arquivo precisa adivinhar o encoding em que os dados foram gravados e às vezes não acertam.

Isso significa que às vezes você vai mandar um arquivo CSV para alguém, ele vai tentar abrir no programa dele e todos os caracteres com acento vão virar um monte de lixo. Ele vai dizer que a culpa é sua de mandar um arquivo corrompido.

Alguns softwares vão abrir em um encoding padrão e se seus dados ficarem todos enfeitados com caracteres ilegíveis, problema seu. Quem mandou você não converter o encoding do arquivo para o encoding usado pelo software. Mas como você ia adivinhar que encoding é esse, se  isso não for uma configuração explícita.

Outro problema é que o caracter usado para separar os dados de registro não precisa ser uma vírgula, como o nome do formato implica (CSV = comma separated values = valores separados por vírgula). Aqui no Brasil mesmo, muitos programas usam o ponto-e-vírgula ao invés da vírgula como padrão.

Mas não existe uma forma de indicar no conteúdo do arquivo qual caracter está sendo usado como separador. Você simplesmente usa o separador que escolher e se ele não for o padrão, na hora de abrir o arquivo em algum programa, reza para que exista alguma forma de escolher qual caracter você usou como separador. Senão vai ter que arrumar uma forma de mudar os separadores do arquivo.

No caso do Windows, o separador padrão para um arquivo CSV é uma configuração regional do sistema. Se se seu amigo canadense te envia um arquivo que ele gerou no Windows dele e tem vírgulas como separadores, talvez você vai ter um trabalho extra para abrir o arquivo em seu sistema operacional com configurações regionais do Brasil e ponto-e-vírgula como separador. E nem todo software vai usar a configuração do sistema.

Você pode ter lido isso tudo e achado que é um problema bobo, fácil de resolver. Basta que a pessoa que vai abrir o arquivo fique responsável por configurar o software que vai abrir o arquivo com o encoding correto e o separador utilizado. Mas essa solução só mostra como esse formato tem um problema grave de usabilidade. Você nunca precisa checar o conteúdo bruto e configurar um software antes de abrir um XML ou um DOC. Esses passos adicionais tomam tempo e aumentam as chances de erro e corrupção de dados.

O software poderia ser responsável por tentar detectar o encoding e o separador. Mas detecção de encoding pode falhar. Detecção do separador também. O que pode gerar corrupção de dados sem que o usuário perceba.

Esses problemas poderiam ser evitados se o formato tivesse sido formalmente padronizado décadas atrás. Existe um documento  que define que o separador deveria ser sempre a vírgula, mas como sabemos isso já não é obedecido. Além disso o documento não se preocupa com o problema de encoding. Mesmo que se preocupasse, já existem tanto software que geram arquivos CSV no formato livre atual, que para fazer alguma diferença, um padrão deveria ter um novo nome e de alguma forma ser adotado em massa pela indústria.

Por conta da longevidade e abrangência da adoção do formato CSV, nós somos reféns dos problemas desses arquivos, obrigados a implementar sistemas que continuem processando esse formato só porque outros sistemas se sentiram na obrigação de dar suporte a CSV, como num círculo vicioso.

Equipes de tecnologia odeiam gerentes não técnicos

Ao conhecer uma pessoa, o profissional de tecnologia começa a classificar: esse pessoa é técnica ou não? Ela já teve que configurar um banco de dados ou uma fila de mensageria? Ela sabe como usar criptografia? Ela consegue entender a arquitetura de um sistema olhando para um diagrama? O quanto ela entende de tecnologia?

Isso não acontece porque técnicos se consideram uma casta diferente que só se relaciona com pessoas da mesma turma. O problema todo se resume à comunicação. Se você precisa explicar algo para uma pessoa que também é técnica, pode levar em conta que ela já sabe conhece algumas informações básicas, e isso torna a explicação mais fácil. E isso torna o trabalho do técnico mais fácil.

Outro problema são as expectativas mágicas que os leigos têm em relação aos técnicos. Por não saber como as coisas funcionam, tentam imaginar como devem funcionar. Por isso na hora de explicar um problema técnico que está tendo, pessoas não técnicas tentam explicar de uma forma que talvez não vá fazer muito sentido para o técnico. Pode ser uma reclamação de que um documento importante sumiu, fazendo o pessoal do CPD perder tempo recuperando o arquivo do backup quando na verdade a janela do Word estava só minimizada.

Por isso, uma situação que cria muita insatisfação é quando o gerente de uma equipe de tecnologia não é uma pessoa com perfil técnico. Normalmente alguém que está no cargo porque tem experiência em gerir pessoas, projetos, clientes. E para muitas empresas, essa estratégia parece natural, já que funciona com outras áreas da empresa, em que os especialistas são os membros da equipe e o gestor só coordena e cobra. Por que a equipe de TI seria especial?

O problema de comunicação entre técnicos e não-técnicos afeta o dia a dia da relação com o gerente. O gerente da equipe é uma das pessoas com que o profissiona de tecnologia mais vai ter que interagir. Se ele não for técnico, você tem esse desgaste a mais de energia tentando explicar conceitos básicos, preparando uma aula só para passar um status do andamento de um projeto.

Dependendo do gerente, suas expectativas mágicas podem causar muito stress para a equipe, principalmente quando ele é responsável por estabelecer os prazos. Para o gerente não-técnico, uma mudança no sistema pode parecer trivial, algo que vai tomar algumas horas. Mas olhando com mais cuidado, um técnico pode detectar que isso vai exigir mudanças grandes que podem tomar meses. E se o gerente não tiver como renegociar esse prazo (ou simplesmente quiser mostrar serviço para seus superiores), a equipe é quem paga o pato de trabalhar fora do horário de serviço para entregar o que foi pedido.

Nem toda empresa pode ou consegue achar alguém com o perfil de gerente técnico. É possível fazer uma equipe técnica e um gerente não-técnico funcionarem juntos, mas é mais difícil. Esse gestor precisa ter humildade e facilidade para aprender um pouco sobre a tecnologia usada por sua equipe, não necessariamente entendendo os detalhes de quem bota a mão na massa, mas o suficiente para entender uma conversa sobre o assunto. Também é importante ter confiança com a equipe, pedindo dos profissionais feedback quando o lado técnico afetar seu trabalho.

Algo que pode ajudar é utilizar a cultura de equipes autogerenciadas, muito difundida na comunidade de métodos ágeis. Nesse caso, o gerente funcionaria mais como um facilitador.

De qualquer forma, ter um gerente técnico pode ajudar muito na hora de contratar novos membros para sua equipe. Na hora da seleção o gerente vai saber o que realmente importa na prática, enquanto o candidato pode se sentir mais motivado de saber que vai trabalhar com alguém que entende o lado dele.

Vale a pena fazer o curso de machine learning do Coursera?

As plataformas de cursos online surgiram nos últimos anos para realizar o sonho de muita gente: poder assistir aulas formuladas pelas melhores universidades do mundo sem precisar sair de casa, enquanto come um Doritos e veste apenas uma cueca. Esse não era meu sonho, mas resolvi que deveria experimentar esse conteúdo pelo menos pela experiência.

Aprendizado de máquina é um assunto que me interessa, por isso resolvi me matricular neste curso gratuito do Coursera. Já havia estudado o assunto antes por conta própria através de livros e até usado um pouco da teoria na prática. Além de poder aprender mais algumas coisas e solidificar o que já tinha visto, essa foi a chance de conhecer e avaliar um conteúdo didático criado em Stanford. É o equivalente para um amante de café ter a chance de experimentar de graça aquele café que é considerado um dos melhores do mundo, feito com grãos retirados das fezes de um roedor que não lembro o nome.

Antes de saber se você deveria fazer este curso é uma boa ideia ter uma noção do que é aprendizado de máquina. E acho que a melhor forma de motivar alguém a conhecer melhor o assunto, é ter uma noção de suas aplicações práticas. Usando machine learning você pode criar software que reconhece objetos em imagens, detecta fraudes em operações financeiras, dirige um automóvel ou drone, avalia o crédito de pessoas, avalia a probabilidade de um paciente ter uma doença, prevê que um servidor pode sofrer uma falha, e muitas outras coisas que parecem mágica. Mas conhecendo melhor sobre o assunto você vai ver que essa lista que fiz é bem limitada.

Depois de se interessar pelo curso, sua preocupação pode ser em saber se você precisa ser um campeão de olimpíada de matemática para conseguir acompanhar o curso. Este é um assunto que usa muita matemática, mas o curso foi pensado para alunos que pelo menos consigam ler uma fórmula com somatórias, matriz e vetores. Existem até aulas opcionais com álgebra linear básica para ajudar com os conceitos que vão ser usados durante as aulas. E graças ao professor Andrew Ng, as aulas são muito didáticas a ponto de ele fazer todos os passos de cálculos necessários nos exemplos. Em casos em que seria necessário um conhecimento matemático maior, o professor dá uma explicação sobre a intuição do que está sendo feito, mas não é exigido que o aluno saiba resolver uma derivada ou decompor uma matriz, por exemplo. Mas minha opinião é que tendo uma base mais do que básica sobre cálculo e álgebra linear vai tornar o conteúdo muito mais fácil de assimilar e entender, sem deixar que alguns passos nos algoritmos pareçam ter aparecido por mágica.

Saber programar é um pré-requisito. Os projetos a entregar são programas escritos em Matlab ou Octave. Mas não é necessário conhecer uma dessas linguagens, pois algumas das aulas vão te ensinar o necessário para realizar todas as tarefas. Eu mesmo nunca havia usado essas linguagens. Apesar de não ser muito difícil de aprender, muitas vezes perdi muito tempo por detalhes da linguagem que causavam erros nas minhas tarefas. Mas o fato de que você só precisar programar o principal das tarefas, com o código que cuida de preparar os dados e mostrar resultados já pronto, facilitou e economizou muito meu tempo, considerando que é um curso que muita gente vai fazer no tempo livre. E o sistema de envio das tarefas com correção automática funciona muito bem. Você resolve cada passo do exercício, envia para o sistema e ele te diz se você acertou ou não.

Um ponto muito positivo é que todo o conteúdo, por ser ensinado pela mesma pessoa, tenta seguir mais ou menos a mesma notação do começo ao fim. Isso ajuda muito para comparar os algoritmos. Quando você tenta aprender cada uma dessas coisas por fontes diferentes, você acaba vendo notações diferentes que dependem da preferência do autor. É como tentar entender uma história que teve uma parte contada por uma pessoa e o final contada por outra, mas a que contou o final só se refere aos envolvidos por apelidos que você não conhecia.

O melhor do curso para mim são as ferramentas que ele ensina para que você entenda se sua solução de machine learning está funcionando bem, e o que você pode fazer para melhorá-la. É esse o conhecimento que eu esperaria de alguém que fosse usar esses algoritmos na prática.

Vejo poucos pontos negativos, que são pequenos perto das qualidades do curso. Algo que me incomoda um pouco são as questões que aparecem no meio dos videos. Muitas vezes eles nem estão testando se você entendeu a teoria que está sendo ensinada, mas verificando se você está acordado e prestou atenção na notação que o professor acabou de usar. Outra coisa que me fez falta, que se deve mais ao formato, é não ter um material que possa consultar facilmente depois. É impraticável procurar no meio dos videos algo que você não lembra direito onde viu, por isso recomendo anotar principalmente as dicas que são baseadas na experiência do professor Andrew.

Talvez algumas pessoas possam se sentir incomodadas pela falta de formalidade técnica que o assunto é tratado, mas considerando que aprendizado de máquina é uma área em que os métodos funcionam mesmo sem os matemáticos entenderem muito bem, acho que o conteúdo habilita alguém a se tornar um praticante. Um conhecimento mais formal seria necessário apenas para quem deseja se tornar um pesquisador na áreae nesse caso este curso funcione bem como uma introdução geral.

Por tudo isso digo que vale muito a pena fazer o curso de machine learning oferecido pela Universidade de Stanford pelo Coursera. Valeria a pena mesmo se fosse pago, sendo grátis eu tenho a vontade de visitar meus amigos programadores e obrigá-los a assistir essas aulas.

Negócios que qualquer programador poderia criar

Depois que o Bill Gates se tornou rico e a profissão de programador se tornou mais conhecida, existe uma expectativa de que pessoas com a habilidade de escrever softwares se tornem empreendedores. Existem incubadoras e investidores nos Estados Unidos que só investem em empresas que têm desenvolvedores em seu time de fundadores. E nos churrascos de família seus parentes estão sempre olhando para você e se perguntando porque você ainda não criou o próximo Facebook.

“Quando você ficar rico lembra que eu te dei a maior linguiça rs.”

E muitos deles pensam em seguir esse caminho, mas esbarram na desculpa da falta de ideias. Eles olham para o que o Google faz e sentem que não tem capacidade técnica suficiente ou que vão precisar de muita ajuda para construir algo. Ou olham para sistemas que as empresas compram como ERPs, CRMs, sistemas de RH e não entendem os problemas que esses produtos resolvem, e por isso não sabem como poderiam criar algo assim.

Mas um programador não precisa ter PHD em Stanford ou ter sócios que entendem de um domínio muito específico de negócio para criar um produto e começar uma empresa. Existem problemas que já estão a seu alcance, e pessoas dispostas a pagar para resolver esses problemas.

Para ilustrar vou dar exemplos de algumas empresas que começaram com produtos que são tecnicamente muito fáceis de construir. Ideias tão simples que provavelmente já passaram pela cabeça de muito programador, mas que por acharem que era simples demais também devem ter pensado que não teriam como lucrar com elas. Ideias que quando você vê funcionando como empresas, fica se perguntando como não pensou nisso antes (mesmo já tendo pensado nisso).

Buffer

A Buffer é uma ferramenta que posta atualizações em suas redes sociais em horários agendados ou calculados. Sua empresa pode usar a ferramenta para divulgar um link em todas as suas redes sociais sem ter o trabalho de entrar em cada site e postar o conteúdo no horário certo.

O básico desse serviço pode ser feito por um script que execute no horário certo (usando um job de cron por exemplo) e faça chamadas de API para disparar a postagem do conteúdo. E na verdade, foi assim que eles começaram.

Hoje a Buffer tem receita de mais de U$ 600 mil/mês, com pelo menos 46 mil clientes, de acordo com seu dashboard aberto na Baremetrics.

StatusPage

A StatusPage fornece um site onde uma empresa que tem serviços online pode mostrar informações sobre o status de seus serviços, e fornecer atualizações a seus usuários sobre os problemas que estão afetando sua disponibilidade. Por exemplo, o Kickstarter usa o StatusPage para atualizar seus clientes sobre o progresso de alguma correção no site caso ele saia do ar por problemas técnicos.

O serviço deles é basicamente um site, algo que poderia ser feito por alguém que não sabe programar. Bastaria saber configurar um CMS. É um serviço tecnicamente fácil de fornecer.

Mas os clientes da StatusPage vêem valor no que eles oferecem. A última vez que a StatusPage divulgou números de sua receita foi em janeiro de 2014, quando atingiram U$ 25mil/mês.

StoreMapper

A StoreMapper fornece uma busca de lojas físicas para que um comércio que tenha vários endereços ou fábrica que fornece produtos para várias lojas permitam que um cliente encontre um endereço onde pode fazer a compra usando seu site.

Criar algo assim poderia ser muito complexo, a não ser que você fizesse como a StoreMapper e usasse a API do Google Maps para exibir os resultados. Isso torna a implementação do serviço muito mais fácil.

Atualmente a StoreMapper tem 889 clientes e receita de U$ 15 mil/mês, de acordo com seu dashboard aberto no BareMetrics.

A sua ideia

Que fique claro que não estou dizendo que é fácil criar uma empresa. O básico de cada exemplo que listei pode ser implementado por qualquer programador, mas é claro que com o tempo esses empreendedores foram melhorando o produto para que ele forneça muito mais valor a seus clientes. Além disso, o sucesso de uma empresa não depende só da parte técnica.

O que quero dizer é que boas ideias para negócios podem vir de problemas que estão a seu redor e que podem ter soluções simples que estão ao seu alcance.