Assim como uma refatoração grande, reescrever um software não é algo simples. Após vários anos, adquirimos experiência suficiente para indicar o que você deve considerar ao planejar e executar um processo para reescrever software.

1. As duas plataformas existirão juntas por um determinado período ou não?

Você planeja manter a versão de legado e a nova versão em produção? Caso positivo, por quanto tempo? Você deve evitar manter duas versões em produção por muito tempo devido aos custos operacionais e de oportunidade.

2. Quem trabalhará na reescrita do código e quem trabalhará na versão do legado?

Geralmente, os desenvolvedores preferem trabalhar em projetos greenfield. Você deve considerar isto ao planejar quem trabalhará na versão do legado e quem trabalhará na nova.

3. É inviável reescrever todas as funcionalidades ao mesmo tempo

Mapear cada funcionalidade entre a versão do legado e a nova é inviável. Dito isto, que funcionalidades devem ser as primeiras a serem reescritas?

Leve em consideração como os clientes atuais serão afetados por um produto com menos funcionalidades.

4. Reescrever o software diminuirá ou interromperá o lançamento de novas funcionalidades na versão do legado

É provável que você não lance novos recursos na versão legada durante o processo de reescrita do código. Assim como os usuários finais, os clientes internos (comercial, produtos, financeiro) não terão novas funcionalidades. Seus clientes internos e outras partes interessadas vão pressioná-lo para entregar novas funcionalidades.

Certifique-se que a comunicação antes e durante o processo de reescrita do software seja clara e que cada stakeholder esteja alinhado com as metas.

5. O processo deve ser secreto ou público?

Imagine que você é um cliente potencial de um produto de software. Você planeja comprá-lo, mas descobriu que uma versão completamente nova será lançada em três meses. Você compraria a versão do legado ou esperaria por três meses? Multiplique isso por dezenas ou centenas de potenciais compradores. O fornecedor pode perder muito dinheiro.

Por isso, se você é o fornecedor, deve pensar cuidadosamente sobre como e quando divulgar o lançamento da nova versão.

6. Migração de dados

O processo de reescrever um software não envolve apenas o desenvolvimento de funcionalidades. Você também precisa planejar a migração de dados. As pessoas costumam subestimar a complexidade e o esforço necessários para migrar dados da versão do legado para a nova versão. Essa atividade não deve ser apenas mais uma tarefa em seu quadro, chamado “migração de dados”. É muito maior que isso.

Por exemplo, imagine que você precisa migrar as contas de seus usuários. Se a sua versão de legado é gerenciada por um terceiro, é provável que você não tenha acesso às senhas criptografadas dos usuários, portanto, não será possível migrá-las. Você terá de solicitar a cada usuário para redefinir a senha na nova versão. Isso também faz parte do processo de migração de dados.

7. Prepare-se para uma possível redução nas taxas de conversão

Você lançará uma nova versão com menos recursos. Quem garante que as taxas de conversão permanecerão as mesmas? As taxas de conversão são essenciais em algumas indústrias, como no e-commerce.

Preferencialmente, você deve manter o suporte à versão legada e à nova por um tempo para que, no caso de redução drástica nas taxas de conversão, você tenha um plano de backup.

8. Planeje treinamento para os usuários internos

Este é outro ponto negligenciado. O plano de reescrever o software precisa ter uma fase de treinamento de usuários internos antes de disponibilizar seu novo produto em produção. Não subestime a importância deste item. Pode demorar algum tempo, pois seus usuários internos darão feedback sobre pontos que talvez precisem ser alterados.

Usuários internos podem ser encontrados em várias áreas, como help desk e vendas.

Leia os outros posts da série Baixa Qualidade Interna de Software

1. Sintomas da Baixa Qualidade Interna de Software
2. 9 Pontos-chaves ao se fazer uma refatoração grande de software
3. 8 pontos-chaves para reescrever um software você está lendo

The post 8 pontos-chave para reescrever um software first appeared on Plataformatec Blog.

Não só bens físicos se deterioram, isso também ocorre com software.

Todos sabem que bens físicos se deterioram. As pessoas aceitam este fato e sempre lidaram com isso. O que as pessoas não aceitam tão facilmente é que software “se deteriora” também. Ao contrário dos bens físicos, isso não acontece devido a algum fenômeno físico ou químico. Essa deterioração ocorre geralmente devido a mudanças de negócios ou de profissionais. Vou dar um exemplo.

Imagine que você é o líder de uma equipe de produto ou tecnologia em uma startup; você é o CTO. Você já lançou a primeira versão do seu produto e foi um sucesso. Seu modelo de negócio foi validado e agora você está em fase de crescimento. Isso é fantástico! Mas tem seus custos, além de novos desafios.

A primeira versão do seu produto está funcionando, mas a base de código não está como você precisa a partir de agora. Talvez sua equipe não seja tão veloz quanto antes. Sua equipe reclama continuamente da qualidade do código. O CEO e o diretor de produto querem novas features e suas estimativas atuais não atenderão às necessidades do negócio.

Não raro, baixa qualidade da base de código está entre as principais origens de todos problemas. Talvez você precise refatorar (refactor) ou reescrever (rewrite) o software.

Quando a base de código não está em boas condições, todos podem ficar frustrados.

Sua equipe inteira, incluindo os desenvolvedores, se sentirão frustrados porque gostariam de liberar features com maior velocidade, porém a qualidade do código e a arquitetura atual não ajudam.

Os departamentos de TI, produto e software sofrem por não atenderem às expectativas das outras áreas.

O cliente também sofre devido aos bugs frequentes, o tempo gasto para que sejam corrigidos, além da demora para lançar novas features.

Você conseguiu entender.

Identifique os sintomas

É papel do líder (por exemplo, o CTO) identificar quando é necessário refatorar ou reescrever o software. Para isso, ele(a) pode fazer uma análise em busca de alguns sintomas, como os listados abaixo:

• Tudo é difícil: Quase todas features novas ou correções de bugs que sua equipe precisa fazer são difíceis. Nem sempre foi assim. Você se lembra dos bons tempos em que sua equipe era rápida e a execução era perfeita.
• Velocidade lenta: a velocidade de sua equipe diminuiu ou está diminuindo. Quando vocês desenvolveram a primeira versão do produto, era rápido desenvolver uma nova feature. Sua equipe conseguia desenvolver um monte delas a cada iteração. Agora é diferente.
• Suíte de testes lenta: Sua suíte de testes apresenta tempo de execução 10x, 20x, 30x maior que antes.
• Bugs que não desaparecem: Sua equipe corrige um bug e em algumas semanas ele reaparece. É comum sua equipe corrigir bugs em testes de regressão.
• Sua equipe está desmotivada: Sua equipe reclama continuamente que trabalhar no projeto já não é tão produtivo como era no antes. Uma pessoa não consegue construir uma feature sozinha; há muitas partes em movimento.
• Conhecimento isolado: Existem algumas partes do software que apenas um desenvolvedor conhece bem o suficiente para mantê-las. O resto da equipe tem dificuldades em trabalhar com esse código específico.
• O período de adaptação de um novo desenvolvedor é muito longo: Quando novos desenvolvedores se juntam à equipe, demora demais para que eles se tornem totalmente produtivos.

A razão pela qual você está em uma dessas situações provavelmente não é técnica. Talvez você precisasse entregar muitas features muito rápido, enquanto ainda estava desenvolvendo a primeira versão de seu produto. Talvez sua equipe não tinha maturidade e experiência que possuem agora. Analisar a causa raiz também é importante, mas você precisa fazer mais. Você precisa resolver o seu problema.

Se você está enfrentando os sintomas acima, provavelmente você tem problema de baixa qualidade interna de software. Reconhecer os sintomas já é um grande passo. O próximo passo é pensar em soluções. Algumas soluções que você pode considerar incluem o processo de refatorar ou reescrever o software.

Refatorar ou reescrever?

Não existe um guia definitivo que aponte quando você deve refatorar ou reescrever o software, pois depende muito do seu contexto. Dito isto, existem algumas regras básicas que você deve considerar ao avaliar qual a melhor solução para sua situação:

Quando reescrever

• Se a tecnologia que você usa está desatualizada e não possui mais manutenção;
• Se seu software é muito lento e mudar a arquitetura não é suficiente ou viável;
• Se a disponibilidade de desenvolvedores de software que conhecem a tecnologia que você usa é baixa e está diminuindo;
• Se existem novas tecnologias que oferecem vantagem significativa em relação a que você utiliza.

Quando refatorar

• Se a tecnologia que você usa ainda possui manutenção e é relevante;
• Se é viável melhorar seu aplicativo gradualmente;
• Se o problema que você está resolvendo é apenas técnico, e não de negócio.

Não é fácil decidir qual opção escolher. Ao optar por uma delas, você enfrentará um monte de novas preocupações. Fique atento, em nossos próximos posts vamos discutir o que levar em consideração antes de optar por refatoração ou reescrita do software.

Agora eu gostaria de saber sobre suas experiências. Você já esteve nessa situação? Como você identificou que o problema era baixa qualidade interna de software? Compartilhe sua história conosco!

Leia os outros posts da série Baixa Qualidade Interna de Software

1. Sintomas da Baixa Qualidade Interna de Software você está lendo
2. 9 Pontos-chaves ao se fazer uma refatoração grande de software
3. 8 pontos-chaves para reescrever um software

The post Sintomas da Baixa Qualidade Interna de Software first appeared on Plataformatec Blog.

As well as a big software refactor, a rewrite is not a simple thing either. After many years, we have gotten experience enough to point what you had better consider when planning and executing a rewrite process.

Will the two platforms live together for some time or not?

Are you planning to maintain the legacy and the new version in production? If so, for how long? You should avoid maintaining two versions in production for too long because of opportunity and operating costs.

Who will work on the rewrite and who will work on the legacy version?

Developers usually prefer to work on green field projects. You should take that into account when planning who will maintain the legacy version and who will work on the new one.

It’s not viable to rewrite every single feature at once

It’s not viable to have a 1 to 1 feature mapping between the legacy version and the new one. That said, what features should you start rewriting?

Take into account how current clients will be impacted by a product with fewer features.

A rewrite will slow down or stop the launch of new features in the legacy version

Chances are you won’t launch new features for the legacy version during the rewrite process. Not only will end-users not get new features, but neither will internal clients (commercial and product departments). Your internal clients and stakeholders will pressure you to deliver new features.

Make sure that the communication before and during the rewrite is clear, and that every stakeholder is aligned with the end goals.

Keep it secret or public?

Imagine you are a potential customer of a software product. You’re planning to buy it, but you just found out that a completely new version will be launched in three months. Would you buy the legacy version or wait for three months? Multiply that by dozens or hundreds of potential buyers. The provider could lose a lot of money.

That’s why if you’re the provider, you should think carefully about how and when you’re going to publicize the launch of a brand new version.

Data migration

A rewrite process is not just shipping features. You also need to plan the data migration. People usually underestimate the complexity and effort needed to migrate data from the legacy version to the new version. That activity should not be just one task on your board called “data migration.”

For example, imagine that you need to migrate your users’ accounts. If your legacy version is managed by a third-party, chances are you won’t have access to the users’ encrypted passwords, so you won’t be able to migrate them. You’ll have to ask every single user to reset their passwords in the new version. That’s part of the data migration process, too.

Prepare for a possible decrease in conversion rates

You’ll launch a new version with fewer features. Who guarantees that the conversion rates will stay the same? Conversion rates are vital in some domains, like in e-commerce.

Ideally, you should be able to keep both the legacy and the new version running for a while so that you have a backup plan in case there’s a huge decrease in conversion rates.

Plan time to train internal users

This is another overlooked subject. The rewrite plan needs to have a phase of internal user training before taking your new product to production. Don’t underestimate that, either. It can take a long time since your internal users will give you feedback about stuff that might need to be changed.

Internal users can be found in a variety of areas, such as help desk and inside sales.

What about you? Do you have any more tips on what to worry about when doing a rewrite? Share with us!

The post Key points to consider when doing a software rewrite first appeared on Plataformatec Blog.

Not only physical matter deteriorates, software does too

It’s known that physical matter deteriorates. People accept that and have always dealt with it. What people don’t accept so easily is that software “deteriorates” too. Unlike physical matter, it doesn’t happen due to some physical or chemical phenomenon. It usually happens because of some business change or people change. Let me give you an example.

Imagine you’re leading the tech or product team of a startup; you’re the CTO. You already launched your product’s first version, and it was a success. Your business model was validated, and now you’re in a growth stage. That’s awesome! But it has its costs, and it brings a new set of challenges.

The first version of your product is working, but the codebase is not in the shape you’ll need from now on. Maybe your team’s velocity is not as good as it used be. Your team keeps complaining about the code quality. The CEO and the product director want new features, and your current projections will not meet the business needs.

It’s not uncommon that one of the main sources of all these problems is the poor quality of your product’s codebase. You may need a refactoring ¹ or a rewrite.

When the codebase is not in good shape, everyone can get frustrated

If the internal quality of your product is not good, everyone becomes frustrated.

Your whole team, including developers, will get frustrated because they would like to ship features faster, but the current code quality and architecture are not helping.

The IT, product, and software departments suffer because they’re not able to meet the expectations of the other departments.

The customer also suffers because of frequent bugs, how long it takes for them to be resolved, and how long it takes new features to be launched.

You get the picture.

Identifying the symptoms

It’s the leader’s job (let’s say the CTO) to identify when a refactor or a rewrite is needed. In order to do that, he or she can look around for some symptoms, like the ones below:

• Everything is hard: Almost every feature or bug fix your team needs to do is hard. It was not always like that. You remember the good old days when your team was fast and everything ran smoothly.
• Slow velocity: Your team’s velocity decreased or is decreasing. When you were building the first version of your product, it was fast to develop a new feature, and your team used to build lots of them every iteration. Now it’s different.
• Slow test suite: Your test suite takes 10x, 20x, 30x more time to run than before.
• Bugs that don’t go away: Your team fixes a bug, then in a week or so it appears again. Every now and then your team is fixing a regression bug.
• Your team is demotivated: Your team keeps complaining that working in the project is not as productive as it was in the past. A single person can’t build one feature alone; there are too many moving parts.
• Knowledge silos: There are some parts of the software that only a single developer knows well enough to maintain. It’s difficult for the rest of the team to work with that specific code.
• New developer ramp-up time is taking too long: When new developers join the team, it takes too much time for them to be fully productive.

The reason you got into one of these situations is probably not a technical one. Maybe you needed to deliver too much, too fast while you were building the first version of your product. Maybe your team didn’t have the maturity and experience in the past they have now. Analyzing the root cause is important too, but you need to do something else. You need to solve your problem.

If you’re experiencing the symptoms above, you probably have a low internal software quality problem. Recognizing the symptoms is already a big step. The next step is to think of solutions. Some solutions you may take include refactoring or a rewrite process.

Refactor or rewrite?

There’s no definitive guide about when you should do a big refactor or a rewrite, because it depends on a lot on your context. That said, there are some rules of thumb that you should consider when evaluating which solution to go with:

When to rewrite

• The technology you use is outdated, and it’s not maintained anymore.
• Your software is really slow, and changing the architecture is not enough or is not viable.
• The supply of software developers that know the technology you use is low and decreasing.
• There are new technologies that offer a significant advantage compared to what you’re using.

When to refactor

• The technology you use is still maintained and relevant.
• It’s viable to improve your application in an incremental fashion.
• The problem you’re solving is just technical and not a business one.

Choosing one of these options is not an easy decision, and once you go with one of them, there will be an entire new set of concerns you’ll encounter. Stay tuned, in our next blog posts we’ll talk about what to consider when doing a big refactor or a rewrite.

Now I would like to know about your experiences. Have you ever been in a similar situation? How did you identify that your problem was low internal software quality? Please share with us!

The post The Symptoms of Low Internal Software Quality first appeared on Plataformatec Blog.