Categoria: Random Issues

As software engineers, what are we really building?

24/11/2014 Career, Random Issues Deixe um comentário

I never liked the bridge building metaphor very much and I know many software developers also didn’t. Many criticize the whole engineer thing and prefer the craftsmanship metaphor.

I can see value in both, but I wasn’t able to express what exactly was the problem with them. At least until a few days ago, when I watched this cartoon with my son about a tractor loader stacking numbered little cubes of various colors.

The building block metaphor

The first thing that came to my mind was the analogy of building software using components. If we think on these components as blocks, we can go even further. When we stack a block on the top of another or gather them side by side we can call the surface touching another block’s surface as the interface between them.

The problem is, in software, greater contact area between two components means coupled code that’s hard to change and maintain, right? However, real blocks benefit from friction and are more stable when they have direct contact with a greater number of blocks. While real blocks support each other, too much friction between software components makes them unusable.

So, when you think a little deeper in this analogy, you realize it didn’t work very well.

The bridge metaphor

Going back to the bridge analogy, after having watched that cartoon, I realized a subtle but crucial difference between a real bridge and that one that fills the gap between client needs and running software.

When professionals build a house, a building, or a bridge they go to the physical place, inspect, measure, do the calculations, bring the material, put each thing in their place. If some material is missing, they just buy more. If something is not fitting in, they just tweak it. When they finish it, they can see exactly whether they met the expectations or not. Of course a bridge can fall, someone can do incorrect calculations, but in general engineers are somehow able to assess its stability.

What can I say about software development? It’s abstract. It can’t be seen. It can’t be measured properly. You can test it in some manners, but it doesn’t guarantee it’s correct. But you already knew about all these characteristics, right? Yet there’s something perhaps you have missed, as I did. That is, in software, we don’t just build and delivery.

Actually, we do not build a bridge at all. What we really build is an abstraction. Not an abstract bridge. We build an abstract bridge builder.

At low level, every time an application is executed it builds a concrete bridge. That bridge needs to fit perfectly unknown places and shouldn’t fall under uncertain weights. In another words, it brings and loads and gathers and connects all components, and when they’re ready it’ll do whatever it was designed to do.

So a software bridge is more like a bridge you can carry in your pocket and use whenever you need to cross some valley or river. Depending on the user, he/she will complain that bridge won’t take them from America to Europe.

And about the Mona Lisa?

I think we can apply the same principle to software craftsmanship. Think for a moment. Even if we switch to this analogy, with developers producing binary masterpieces and programmers painting Mona Lisa’s, it doesn’t change anything in the nature of that problem.

We’re still making an abstract artwork builder. When the software runs, it should creates instantaneously a masterpiece according to the instructions of its master.

Is there a proper analogy?

Sorry for disappointing you, but in fact I have no idea. 🙁

On the other hand, I have strong reasons to think that much of our problems in software engineering will be solved by finding the right analogy.

As cubes and rectangles and circles are properly used as abstractions to build bridges and paint masterpieces, it there should be proper abstractions to software development.

One thing I do know

As software developers (engineers or craftsmans) we should be simple. We need master simplicity.

I think it’s clear for anyone who have ever worked with software that complexity should be avoided at all costs. It’s not by chance the latest frameworks and tools and processes and methodologies and techniques try to be as simple as possible.

Nevertheless, I have something against them. They’re becoming too shallow.

For instance, I’ve seen many people doing agile because they hate documentation. But throwing it away won’t solve their problem. I’ve seen many new flavors of tools and frameworks and methodologies that do exactly what the existing ones do, except for promising they’re easier. I’ve seen people that hate everything that seems to be old and love every novelty though they have no clue about the reason.

They just want to work less. They just want to think less.

We’re living the era of lazy programmers. But not the kind that would automate repetitive tasks, as noticed by Steve McConnell in his book Code Complete, or avoid useless documentation. Unfortunately, there are plenty of lazy programmers today that don’t even want to understand the problems they face. They want some magic easy solution so they don’t need to think and do the hard work.

Simple but deep

When you have a problem, there’s basically two alternatives: ignore it and hope that soon or later it’ll disappear, or face it and do whatever it takes to solve it.

Despite many advances in the field, I think we’re still living a software crisis. I see many companies and professionals completely lost having so many options to do the same thing, while others jump from technology to technology by a matter of taste.

Well, I have my personal taste for programming languages too, but that’s not the point. I’m talking about the fundamentals. I think people are just attacking the wrong thing. They’re ignoring the real problem.

It’s not sufficient to make things easy and cool without solving the real problem.

Software development today is simpler than some decades ago. Nonetheless, as spotted in Brooks’ Mythical Man-Month, it happened because we overcome the accidental difficulties of programming. We have now better debugging, rich-featured IDEs, faster personal computers, and son on. But few initiatives attack the essence of the complexity in software development. And here dwells our biggest challenge.

In order to make software development even simpler, it’s necessary to dig deep into the dirty of complexity, face the hard things, try solution after solution, year after year.

We need people that do not put blind faith in new tools and methods, that aren’t lazy to do whatever needs to be done, that really understand what they are doing. And we need people willing to persist in this direction, instead of being apathetic and choosing the easy path.

Only those who discipline themselves in this craft will be able to provide us with a real improvement in software development some day.

software engineering

Stack Overflow and TDC 2014

08/09/2014 Random Issues Deixe um comentário

On August 6 (2014), I went to TDC (The Developer’s Conference) in Sao Paulo, Brazil. As one of the Stack Overflow in Portuguese moderators, I was invited by SO team itself, as they sponsored the event.

If you don’t know yet, the most essential site for developers, Stack Overflow, debuted this year its Portuguese edition. The goal is to provide useful and quality information, in its well known Q&A format, for millions of Portuguese-speaking programmers that aren’t very comfortable with English.

Talks

There were some very interesing talks and I highlight What Do Programmers Care About by Joel Spolsky, founder of Stack Overflow and of the acknowledged site joelonsoftware.com.

He spoke about the challenge to find and retain talented programmers, highlighting a few characteristics that professionals seek in companies.

One of the high points, in my opinion, was the idea that companies that try to save with tools and hardware pay a far higher price, since each delay in development process waste their more expensive resource: the developer time.

If you participate of the hiring process in your company, I suggest strongly for you to watch another version of this talk available on YouTube.

Networking

The most funny part of this event was meeting Stack Overflow team in company’s booth, as some SO users I knew only through the site, and many other people passing by.

Have a look how busy they were in these photos!

Actually, I believe this was one of the busiest booths. Those who arrived there early got t-shirts and other freebies, which unfortunately vanished very soon.

I talked fairly with Gabe, the Community Manager from Stack Overflow in Portuguese, who is the ~~(guilty)~~ responsible for the smooth progress of the Portuguese-speaking community. I’ve also talked a bit with one developer of the SO team, which was experimenting React.js and go language in a new project.

I couldn’t help myself from taking a striking reminder of the event. In the photo below, from left to right, you can see me, Joel and Bruno (the other moderator from Stack Overflow in Portuguese).

Official release of Stack Overflow in Portuguese

Stack Overflow in Portuguese went through private and public beta. Participating of TDC, as one of the major IT events in Brazil, was a way to officially release the site, after its initial success.

After TDC, SO held a fellowship for major users, including some new friends that were passing by. It was to be a closed event, but Joel just twitted to everyone. 😀

In this photo, some of the main site users (including me at left):

stackoverflow

Desafios na carreira de um desenvolvedor

31/07/2014 Random Issues Deixe um comentário

Programador, Analista, Desenvolvedor, Engenheiro de Software. Não importa qual o título adotado. Você escreve código? Então é mais um que caiu nessa “cilada”! 😉

Brincadeiras à parte, a área de desenvolvimento de software é uma das mais comentadas, desejadas, amadas e até odiadas da atualidade. Sendo sua história relativamente recente, ainda há muita confusão sobre a identidade do profissional de TI.

Isso se reflete na dificuldade de muitos, senão todos, profissionais ao tomar decisões sobre carreira. O que devem estudar? Vale a pena saber a linguagem X? Em que se especializar?

Todos já ouviram o mantra de que em TI “é necessário estar sempre se atualizando”. Esta é mais uma frase pronta que, de tantas vezes repetida, já perdeu completamente o significado e o impacto em nossas mentes.

Quero agora levá-lo a uma breve reflexão sobre o seu desenvolvimento como profissional e tentar responder de forma geral às indagações acima.

Sim, TI é complicada

Brooks escreveu na edição especial do livro The Mythical Man-Month, lançada em 1995, que ele já não conseguia mais acompanhar o avanço em todas as áreas da Engenharia de Software como antigamente. Quem dirá hoje!

A situação piorou muito. A cada ano aumenta a gama de conhecimento, plataformas, linguagens, frameworks e ferramentas. Os formandos que vão trabalhar com software precisam sair da faculdade dominando conceitos que foram formulados ao longo de anos, décadas e até séculos. É como se cada turma saísse da faculdade sabendo menos que a anterior, já que existem sempre novidades e o gap de informação aumenta.

Essa gigantesca gama de informações faz com que muitos fiquem ansiosos sobre a infinidade de tecnologias a serem aprendidas. E as empresas parecem procurar super programadores que parecem já ter nascido sabendo tudo.

Algumas vezes já fiquei bastante ansioso por conhecer tão pouco e ver cada dia novas tecnologias sendo lançadas. Parecia nunca ter fim!

Não se desespere

Apesar do cenário acima, precisamos compreender que leva tempo para se aprender bem qualquer profissão. Alguns dizem que leva uma média de 10 anos para alguém ser realmente bom no que faz. E pesquisas indicam que passamos a gostar mais do que fazemos proporcionalmente ao tempo que nos dedicamos aquela atividade.

Além disso, não se deixe levar por aquelas milhares de siglas que você não entende, por exemplo quando você olha aquelas vagas de emprego que pedem centenas de conhecimentos que você nem tem ideia do que são. Isto é algo possível de se conhecer com o tempo.

Não estou dizendo que é fácil. É preciso se esforçar bastante, mas o segredo é ter calma, paciência e persistência. Então você poderá planejar seu avanço profissional dentro de suas capacidades e estudar rotineiramente sem desistir ou desanimar.

Ninguém nasce sabendo

Você não precisa saber de tudo para atuar numa certa área. Aliás, faculdade ou curso algum vai ensinar o que é realmente preciso para encarar um trabalho desafiador ou mesmo empreender em seu próprio negócio.

Basta aprender o necessário para cada fase de sua carreira. Para quem está começando em TI, o importante é conhecer bem os fundamentos da computação, orientação a objetos e pelo menos uma linguagem de programação. Depois disso, é importante intercalar ciclos de estudo e trabalho prático para começar o amadurecimento profissional.

Em minha experiência é importante pensar iterativamente, isto é, em ciclos. Você pode traçar uma meta de aprender profundamente sobre uma tecnologia por ano ou a cada 6 meses, dependendo do seu ritmo. Aí você pode gastar o primeiro mês estudando livros e apostilas, o segundo implementando um protótipo simples, o terceiro estudando um pouco mais a fundo, o quarto tentando criar um projeto mais sério, o quinto lendo material mais difícil sobre o assunto e assim por diante.

Especialistas

Persistindo nos estudos, muitos profissionais acabam se especializando num subconjunto de conhecimentos de uma das áreas de TI. Tornam-se especialistas.

Isso fica bem visível ao analisar alguns eventos de TI. É possível observar diferentes nichos de tecnologias, com palestras e cursos voltados para cada subcultura de TI, cada uma com um público bem específico.

É bom especializar-se em algo. Trabalhar e estudar diferentes aspectos de alguma tecnologia por alguns anos é um grande investimento, pois você passa a ser distinto dentro desse segmento.

Porém, a especialização tem lados positivo e negativo.

Especialistas e especialistas

Como mencionei, há algumas pessoas que são especializadas porque se aplicaram consideravelmente em conhecer determinado assunto.

Por outro lados, outras são “especialistas” porque não se aplicaram em conhecer nada além daquilo que já usam no dia-a-dia.

Enquanto os especialistas de verdade estão dentro da média na maioria dos assuntos e dominam sua especialidade, há os falsos especialistas que não se interessam por nada que não é necessário para eles.

Respeitando a individualidade

Devo fazer uma consideração aqui. Precisamos entender que nem todas as pessoas que trabalham em TI são aficionadas por programação ou questões técnicas.

Conheço bons profissionais, organizados e produtivos, mas que não chegam perto de serem bons programadores. Nem todos os “especialistas” e bons profissionais são necessariamente bons programadores. A Engenharia de Software possui muitas disciplinas que envolvem outras áreas.

Não devemos cair no grande erro de muitos educadores no decorrer da história, o qual tem impactado nossa geração inteira. Estou falando da padronização do que é considerado “inteligência” ignorando as singularidades de cada indivíduo. Isso nada mais é do que dar vantagem a um perfil específico em detrimento dos demais.

Muitas empresas e muitos profissionais ignoram isso e inconscientemente geram incalculáveis prejuízos para si mesmas. Aliás, os profissionais que coordenam processos seletivos deveriam ser os melhores da empresa, porque nada como um excelente profissional para identificar as potencialidades dos entrevistados. Porém, o que geralmente ocorre é que essa tarefa fica relegada a profissionais, no mínimo, medíocres. E o resultado são contratações, no mínimo, medíocres.

Enfim, se você não é um programador, ainda pode aplicar todas as dicas que tentou passar aqui em sua área de conhecimento.

Generalistas

Outro perfil profissional é do generalista, isto é, aquele que estuda diferentes áreas, não ficando muito tempo em apenas uma coisa.

Por muito tempo ouvi críticas a esse tipo de profissional. Você já ouviu algo como “saber pouco de tudo é não saber nada de nada”?

Pois bem. Há até um certo fundo de verdade nisso. Se um profissional troca frequentemente de trabalho, mas não se aprofunda em nada, seu destino será exatamente esse: não saberá “nada de nada”.

Por outro lado, veja a tendência do mercado mudar fortemente nos últimos anos. Antes todos queriam espacialistas. Hoje, os profissionais mais valorizados são os que possuem uma visão abrangente da Engenharia de Software, mas conhecendo o que fazem profundamente.

No entanto, colocarei esses profissionais numa nova categoria…

Generalistas especialistas

Que diacho é um generalista especialista?

Após alguns anos de mercado, analisando vagas em grandes e pequenas empresas, notei uma tendência no perfil mais desejado por boas empresas.

É mais ou menos assim. O profissional deve:

Ter pelo menos 5 ou 7 anos de experiência
Dominar pelo menos 2 tecnologias
Ter conhecimentos intermediários em várias tecnologias
Conhecer o básico de todos os conceitos importantes da Ciência da Computação e Engenharia de Software

Obviamente esses valores e as estatísticas são uma média arbitrária da minha cabeça, mas serve bem para ilustrar meu ponto aqui. Vou traduzir isso em alguns princípios e estou certo que será útil para você.

1. Experiência

Os anos de experiência na verdade não são tão importantes em si mesmos. A questão toda está na maturidade do profissional.

As empresas e os próprios desenvolvedores querem alguém que agregue à equipe e não que seja um atraso. É uma realidade cruel para os novatos, mas a verdade é que hoje não importa muito se você é um gênio em matemática ou em programação. Os desafios mais comuns da Engenharia de Software estão em outras áreas, principalmente nas relações humanas. E, convenhamos, poucos recém-formados são habilidosos em trabalhar com pessoas.

Além disso, não importa se você sabe uma linguagem de programação de cabo a rabo. Resolver problemas complexos da via real exige uma carga de conhecimentos em diferentes áreas.

2. Especialização

Para entregar software no prazo e com qualidade, além de corrigir os problemas mais difíceis, o profissional deve dominar a tecnologia com que trabalha.

Porém, conhecer uma única tecnologia não é mais suficiente.

A grande maioria dos sistemas desenvolvidos hoje são web. De início, podemos dividir esses sistemas em back end e front end. Se você é da área, deve saber que em geral as tecnologias de um e de outro são completamente diferentes. Por isso, é comum hoje um bom profissional que domina .NET ou Java também dominar Javascript, HTML e CSS.

Note que não estou falando em conhecer um pouco de cada tecnologia, mas sim em ser altamente proficiente em várias delas.

3. Generalização

Com a grande variedade de tecnologias disponíveis, o profissional que conhece pelo menos em nível introdutório o funcionamento básico de cada uma, além dos conceitos que dão suporte a essas ferramentas, terá muito mais capacidade de escolher a solução mais correta e adequada para os diferentes desafios.

Isso parece contradizer o tópico anterior, mas não é bem assim. Se você domina pelo menos uns dois paradigmas de programação e tem bons fundamentos técnicos, provavelmente se dará bem com qualquer novidade. Este é o ponto: um generalista é muito mais adaptável a novos desafios.

As antigas guerras de “Ruby vs PHP”, “Python vs Perl”, “C++ vs Java” simplesmente acabaram, exceto para alguns que faltam em maturidade.

Hoje os bons profissionais sabem que não é preciso escolher uma linguagem definitiva. Você poderia usar todas ao mesmo tempo, se quiser. Aliás, em determinadas situações você deve usar um conjunto delas no mesmo projeto.

4. Visão abrangente

Primeiro, desenvolver software não é apenas digitar código. Tenha em mente que para programar bem você deve sim conhecer os fundamentos da Ciência da Computação.

Não vou menosprezar quem aprendeu por conta. Alguns conseguem. Mas não pense que nesta área você será um bom profissional sabendo apenas digitar comandos numa linguagem qualquer.

Estruturas de Dados, Sistemas Operacionais, Geometria, Cálculo, Estatística. Tenha certeza que, cedo ou tarde, disciplinas que lhe faltam poderão ser um empecilho para uma atividade de mais alto nível, a não ser que você queira fazer sistemas de cadastros e relatórios pelo resto da vida.

Segundo, desenvolver não é apenas programar bem. Se você tem alguma experiência em projetos, já deve saber que a programação em si é apenas uma parte de uma grande cadeia de comunicação, motivação, acordos, burocracia, egos e muito mais. Saber lidar com tudo isso é o que realmente irá levá-lo a algo maior.

O perfil do profissional ideal

Escutamos repetidas vezes que as empresas procuram o profissional com experiências nas tecnologias X, Y ou Z. Pode até ser verdade em muitos casos. Porém, quem já trabalha em TI há mais tempo sabe que bons profissionais, com bons fundamentos teóricos, podem aprender qualquer linguagem ou tecnologia.

Outra habilidade importante é a de realmente produzir coisas úteis. Pode parecer estranho, mas muitos profissionais com boa formação e conhecimento abrangente têm dificuldade em implementar ferramentas e sistemas que tenham algum valor para os clientes. Pode ser porque eles deem excessiva importância a minúcias técnicas ou não consigam entender o que o cliente realmente quer, mas seja qual for o motivo por detrás disso, o código que eles produzem é bom só para eles mesmos.

Já o profissional ideal é aquele que consegue compreender os usuários do sistema e implementar, tecnicamente da melhor forma, exatamente aquilo que o usuário precisa.

Por último, mas não menos importante, vou citar as habilidades interpessoais. Inclua no pacote boa capacidade de comunicação e uma personalidade agradável para então ter um profissional realmente “perfeito”.

É claro que na maioria das vezes essas questões de comunicação e relacionamentos são extremamente subjetivas. Elas acabam ficando de enfeite nas descrições de vagas e grande parte dos entrevistadores não dão importância a isso. Mas não se engane! A personalidade é um fator chave para o sucesso e fracasso de toda uma equipe.

Qual seria a personalidade ideal? Aquela que faz as pessoas se sentirem bem ao trabalhar com você. Um profissional que deixa o ambiente da empresa ruim gera um prejuízo incalculável. Porém, se os membros de uma equipe encontram em um profissional alguém com quem realmente desejam trabalhar, este profissional deveria ser mantido na empresa a todo custo.

Como chegar lá

Todo esse papo pode deixar você com um grande peso nas costas. Mas, como já disse, deixe a ansiedade para trás.

Se você é da geração Y ou, pior, da geração Z, mude sua disposição e saiba que todas as coisas boas levam tempo para serem construídas e tem um custo associado.

Primeiro, se você acha que sabe tudo, conscientize-se de que então não sabe nada.

Segundo, Aprenda conceitos e fundamentos sólidos. Não tente seguir todas as ondas e modinhas tecnológicas. Por exemplo, aprenda muito bem orientação a objetos antes de dizer que sabe C++, Java, Scala, Go. Aprenda o que é programação funcional antes de dizer que sabe Javascript. Aprenda sobre redes e protocolos antes de dizer que sabe desenvolver um sistema web.

Crie um planejamento de estudos. Quais são as coisas mais importantes e prioritárias para se aprender na sua área?

Estude frequentemente, não muito intensamente. Se você quer aprender bem Java, por exemplo, pode estudar para obter a certificação. Você vai precisar ler mais de 800 páginas. Faça um plano de estudos de 6 meses a 1 ano, dependendo do seu ritmo. Pode parecer muito, mas lembre-se que tudo leva tempo.

Conclusões

Você pode estar ansioso por alguma pressão externa. Então espero que este artigo tenha lhe acalmado.

Por outro lado, se você fica ansioso porque quer progredir muito rápido, tenha cuidado para não se decepcionar.

Se você acha que sabe muito mais do que pessoas mais velhas e mais experientes, talvez achando que a empresa não te reconhece, também tome cuidado. Faça entrevistas em empresas melhores para tirar a prova disso, pode ser uma lição de humildade.

Alguns programadores acham que são melhores que os chefes porque estes não conhecem tanto sobre uma certa linguagem ou certas novidades. Sim, em alguns casos pode ser verdade, mas na maioria das vezes falta maturidade em compreender os desafios diários que ele precisará enfrentar.

É o mesmo caso de tantos jovens que acham fácil programar e tentam empreender, só para depois perceber que não conseguem clientes o suficiente ou não dão conta das demandas técnicas e da gestão do negócio.

A experiência mostra que os inexperientes acham que tudo é fácil. A maturidade de um proporcional vem sempre acompanhada de sua capacidade de enxergar os desafios que ele precisa enfrentar e as consequências de suas decisões.

Enfim, não tenha pressa, estude sempre e aproveite todas as oportunidades que tiver para aprender e se relacionar com outros profissionais mais experientes.

For my right to no loger use Mozilla Firefox

10/04/2014 Random Issues Deixe um comentário

Alert: this article contains political issues and is based on personal opinions. If you are squeamish, please stop right now.

Thursday, April 3th, 2014.

Mozilla Foundation announces the step down of his CEO, Brendan Eich, less than two weeks of his appointment.

Brendan is, no more and no less, the creator of Javascript language and co-founder of Mozilla project and Mozilla Foundation. Event though his impressive professional history and contributions to open source community were not enough to hold his position as CEO.

As Fox News reported, there was a big pressure by some employees and many comments on Twitter because in 2008 Brendan donated one thousand dollars to support Proposition 8, a state constitutional amendment to provide that “only marriage between a man and a woman is valid or recognized in California”.

No, you don’t read it wrong. I’ll translate: a few gay right militants could not live with the idea of working to someone who thinks differently and six years ago used his own money in something they reprove.

And things are getting worse. Bumbling articles, trying justify all that, claimed that “Eich’s stance was unacceptable in Silicon Valley, a region of the business world where social liberalism is close to an universal ideology”.

Translating again: you are unacceptable to such duty unless you are a liberal and, as a consequence, support same-sex marriage.

Personal comments

I wrote this article because this is just one of many cases of intolerance inverted around the world. Alleged victims persecute and attack the “intolerant”. So, if most of the workers of a company are conservatives, can they fire their boss because he is a liberal?

I’m a Christian, on right politically, against socialism and communism, advocate of homeschooling and moderate children physical discipline and so on. Besides that, I don’t judge the professional capability, intellectual faculties or the character of my colleagues by their personal positions that certainly are different and diverse, neither I use ploys against them.

I have no problems in lead or be leaded by people that think differently. It’s part of someone’s maturity and ethics be careful in speaking about personal convictions in order to not offend others. The problem is, in today’s world, it’s not a two-way street. Soon I will renounce because someone will search out the internet to something “controversial” I published in order to demoralize me.

We live in an upside down world. Kids try to subject their parents, students their teachers, criminals the officers and minorities the majorities. Anyone who feels like a victim, offended by any reason, think he has the right to attack everyone. Grownup people are short.

I am for freedom, but not only of liberals. I am in favor that we could be free, both you and me.

Practicing my right to no longer use Mozilla Firefox anymore

For now, I can only use my right to no longer use Firefox and democratically talk about my position and invite you to do the same.

Do not support an institution that discriminates their employees by their personal convictions.

Do note participate in liberal fascist groups or discussions, that do not tolerate nothing unless their own ideas.

Uninstalling FF in 3… 2… 1…

News about this blog!

07/04/2014 Random Issues Deixe um comentário

New high: 10,000 views

This blog has grown.

In the first months, it had only about 10 daily views. The average increased continuously and today it goes beyond a hundred, with peaks of 160 views. A few days ago, this site reached ten thousand views milestone, summed up since last year June.

New horizons: English articles

The goal of this blog is contribute to IT community. Nothing better to reach more people than using the world’s IT “official” language.

It’s with great pleasure that I announce today the launch of the internationalized version of this blog! Notice the flag on the right.

I will continue to write primarily in Portuguese. However, I’ll start to translate the current content. Portuguese speakers won’t lost anything if they just ignore the other language.

At the present, only a small part of the accesses comes from another countries. My intent is to raise the international visibility of the Brazilian community of developers through this blog, even though with such a small contribution.

But, I have to confess, there is a double intent in all that: practice my English skills. I have already written some articles on how to improve the overall English comprehension reading books. Well, it’s time to do the same in writing.

Exactly because of that I left a big yellow alert saying My English is beta. That’s right. Not only Google and other companies that adopt agile principles can put unpolished “products” in “production”. 😉

What you should to expect

Making my work and thoughts public is not always easy. As I have written, I am exposed to critique and criticism. Something published online is like a tattoo: once done, you’ll never erase it completely again. I’ll do my best to maintain the quality in a high standard.

Moreover, the issues remain divided in four big categories.

The first one contains technical tips of programming. They can be simple or complicated, but I’ll try to post those who can save the life of a poor programmer in despair. Most of this tips come from such situations that happens on sites like StackOverflow.

The second contains reflections about Software Engineering. For instance, when I write about software development problems or difficulties on estimation.

The third refers to Software Architecture. I plan to write a series of articles introducing various technologies to serve as a reference for developers. Furthermore, articles on how to choose and use specific technologies will be part of this category.

Finally, I’ll continue to share thoughts about career and professional development. I regard this as essential. My intent is to administer it continuously in order to lift some professionals from lethargy, where one day I was.

I believe the four aforementioned topics are fundamental for good Software Engineers and will produce good results if administered with right proportions.

Thank you, dear reader

Writing to nobody can be a stress reliever. But it’s much better to know you’re coming, reading, sharing and commenting.

So, thank you!

Please, keep liking, sharing and commenting.

It’s for you.

What is a Legacy System?

19/09/2013 Random Issues Deixe um comentário

If you work with IT, certainly you already heard about “legacy systems”. However, unless you have searched about it by yourself, I doubt someone took the time to explain what it really means. As in many lingoes, people often just use it without really knowing its meaning and are ashamed of telling they don’t know what it is. So legends emerge. After all, we all born knowing such an obvious thing, isn’t?

Defining a legacy system

What is a legacy system? One says it’s an old system, another a system “received” from others or even a system that cannot be modified. Indeed, there isn’t a unified definition of legacy systems, but there is a set of indicators we could loot at. Let’s see some of them:

Lifetime

An “old” system, built relatively a long time ago, isn’t necessary a legacy. The lifetime is certainly an indicator, but not a definition.

Usefulness

A system that isn’t used anymore is not a legacy system. A good indicator is a system that’s essential for the business and cannot be abandoned, even though sometimes people would want to.

Obsolete Technologies and Hardware

A third indicator of a legacy system is its obsolescence. Some systems work on ancient hardware, such as mainframes, which components are costly and rare. Deprecated programming languages, development tools, protocols, database systems and data formats are also important to be considered.

Maintenance

Another tip about a legacy can be detected when all the original developers are retired or left the company, being difficult to replace the workforce. Actually, if people prefer to die instead of working on a software, probably there is a legacy system involved.

Documentation

A few authors claim that a characteristic of a legacy system is lack of documentation. I completely disagree. In this way, the majority of modern systems would born as legacies. 😉

However, if no one knows the business rules behind it and it’s impossible extract them from the implementation, that certainly indicates a legacy system.

Creating a legacy system

Specific decisions and actions, or the lack of them, collaborate in making legacies.

Don’t design properly

The main act that produces legacy systems occur just in its conception. A critical system, from business point of view, without a good design inevitably will become a legacy quickly, as soon as it’s deployed and people realize new features are hard to be added.

Don’t refactor

The system’s complexity grows when it’s modified to meet new requirements. We can call it “entropy”. When code is changed or added without any control, it becomes more and more unorganized and difficult to understand. Without refactoring and internal improvements of the architecture, it would reach a point where will be almost impossible to make any modification without break something.

A friend of mine used to say: “this system is like a short blanket, you cover your feet and it uncovers your chest, you cover your chest and it uncovers your feet”. Did your hear of cases when for each bug fix, two new bugs arose? I heard about a company that chose don’t fix a system because they feared it would not work anymore, since the consequences of changes were unpredictable.

Conclusion

We looked at various indicators of a legacy system, then a few items about how we, as developers, contribute to their appearing.

A more generic and broad definition of legacy system, which I learned from an advisor and professor, goes like this: from a point in the lifetime of a system, its architecture becomes complex enough to make the cost of maintenance higher than the cost of building a new one. There are some issues in this definition, but I won’t go into details. The main idea is: if the cost to add new features is a great constraint to the business, we have a legacy.

There is not absolute rule to define what a legacy system is, but such knowledge about this type of system surely help in management decisions and also in the development of new systems, since we’re able to take actions against the growing complexity in order to make system’s lifetime longer.

legacy system