1

To rewrite or not to rewrite a software

To rewrite or not rewrite a software ?

Writing a software is a incredible difficult task. When the time has come for the software to know the retirement : should we rewrite it ? or have an progressive approach ?

TL;DR

Here are my thoughts on that subject.

In a previous article, I wrote about how to migrate a legacy software. I have planned, programmed, handled several software progressive migrations using dedicated tools in my career. I have created a small company Byoskill, to handle these subjects.

Since, I have been using some facts to decide between a full rewrite and a progressive migration.

The presentation below has been produced for a customer software some time ago and I will use it as an example.


Why writing a software is difficult ?

Let’s be honest together. Writing a software is incredibly difficult. Your latest framework choice won’t change the thing. Neither the most beautiful functional language.

A good software takes team players, the right environment, some skills and experience, efforts and luck. Capers Jones has written several interesting articles about the success and the failure of Software projects.

Probablity of On-time Software Delivery

Probablity of On-time Software Delivery

These tables illustrate the difficulty to lead to a successful project.

Probability of software project termination in six subindustries

Probability of software project termination in six subindustries

Capers Jones interesting articles here and here.

My first argument to be taken into account in the debate pro or con rewrite is the following :

A legacy software is a software that had enough success to ages. Thereby a convergence of facts allow ed him to born, grow up with new features, get fixed and finally ages.

My second motivation based on Capers Jones observations and a lot of similar experiences I encounted in the business of software migration.

Big software projects aka big rewrite are doomed to fail.

The fluctuating market

The conditions that enables the current software to live have probably changed in the recent years. Basically, our software is fighting against the following tendencies :

    • Complexity is the software is increasing
    • Market is not waiting for releases and its appetite is growing for new features
    • Disruption is everywhere : competitors, startups , pricing war
    • ROI law has changed in favor of the scalability and the  number of users rather than higher license prices
    • Low-qualified workers used for maintaining an existing software  are not a appropriate answer to create state of the art technologies.
    • Creating new software (aka rewrite) requires true software leaders and informed product owners
    • Change management is a tricky and nasty affair

The situation has to be evaluated precisely. Will your customers wait for this brand new version ? How will you managed their expectation for the new features ?

Can all the software be saved ?

This tricky question is probably the real rationale behind the pro/con debate in favor of a rewriting.

Basically you have three choices in front of you :

Software migration choices

Software migration choices

Outsourcing developments

The easiest and safest choice for a manager. To not decide anything 🙂

Basically, transfer your legacy software to a company that will promise cheaper rater and cost. Keep the possibility to switch when the outsourcing company will increase their rates.

Blame them and plan your future new projects while keep the cost indicators low for the current solution.

Sole problem : you do not know when you will be able to launch the new projects. Your budget is most likely melting as your maintenance cost.

The Big Rewrite

 

The Big Lebowski

The Big Lebowski

To enable a big rewrite, you need to basically have the following warranties :

  • You have enough time to build your new software
  • You have the full endorsement of your customers, your users and your stakeholders
  • Your business knowledge is perfect and synchronized with the current market need
  • Your users are not expecting the same software ( features, workflow and yes bugs)
  • And all basic conditions to lead a project (cleancode, software craftmanship)

I believe that a successful rewrite project is basically not a rewrite.I would even recommend to not call it “new version” of the product. Rather a new name, a new UI, a new customer/user journey. Calling it a new version of a product where most of the features are missing is always a bad idea.

Progressive migration and automatic migration

Even if these two approaches are fundamentally different, the progressive migration and the automatic migration shares the same goals.

The goals to achieve could be the following ones :

  • Reduce the time of migration : shorter is the project, higher will be the success probability
  • Keep the most useful features, saves money for the new ones
  • Performs critical technical debt operations
  • Avoid any complications in the change management (political issues, conservative users)

I would recommend these scenarios when you have optimal working conditions. Indeed you will have to handle some highly technical software re-engineering.

  • a great motivated team
  • a supporting management (refers to point 1)
  • a whole set of features
  • difficult constraints (time, political, market)
  • some experimented programmers and architect oriented.
  • a evolutionary technology stack allowing easy interactions with a new stack (no proprietary languages, no 4GL)
  • possibility of functional data layering

This article has been already too long to detail the refactoring steps.  I will encourage you to reed the other articles on my blog like this one for a preview.

I hope you will have learn one thing or two about the decision process about rewriting a software. If you have arguments in favor or against what I have advised it, please let a comment!

All these informations are extracted from my experience with byoskill.com. I am offering cleancode courses and support for automatic software migrations.

0

My weekly DZone”s digest #1

This is my first post that offers a digest from a selection of DZone’s articles. I will pick DZone’s article based on my interests.

This week the subjects are : BDD Testing, Bad code, Database Connection Pooling, Kotlin, Enterprise Architecture

A few benefits you get by doing BDD

A few benefits you get by doing BDD : This article is an introduction to the Behaviour Driven Development practice. It’s interesting because we are regularly meeting teams, developers, architectures (pick your favorite one) that are confusing technical details and functionalities. As a result, the design, the tests and the architecture hides the user behaviour (the use cases ?) under a pile of technical stones. This article is a nice introduction. I recommend to go further these articles : * Your boss won’t appreciate tdd, try BDD * BDD Programming Frameworks * Java Framework JBehave.

Gumption Traps: Bad Code

Bad code, how my code...

Bad code, how my code…

Gumption Traps: Bad Code : an article about the bad code and how to deal with it.

{% blockquote Grzegorz Ziemoński%} The first step to avoid the bad code trap is to stop producing such code yourself. When faced with existing bad code,one must work smart to maintain motivation. {% endblockquote %}

This is a good introduction sentence. This week, I had a meeting with a skilled and amazing team. The meeting’s goal was to find a way to find the technical debt. The very technical debt that is ruining the application and undermining the team’s motivation. What I found interesting and refreshing in this article, is the pragmatic tone and the advice.

{% blockquote Grzegorz Ziemoński%} To avoid bad code, try to minimize the amount of newly produced bad code. {% endblockquote %}

How to avoid the depress linked to the bad code ? First of all, I want to say that developers are not receiving enough training on how to improve the code. Usually university / college courses are dedicated about How to use a framework. Therefore, few of them are able to qualify what is a bad code, what are its characteristics and de facto the ways to improve it. To avoid bad code, I try to demonstrate the personal benefits for the developers to improve their skills. Quality is not only a question of money (how much the customer is paying) but rather how much your company is paying attention to your training and personal development.

A lot of developers are overwhelmed under the technical debts without the appropriate tools (mind, technics, theory) to handle it. I try to give them gumptions about the benefits to be a better developer and how to handle the weakness of a sick application. To save a software rather than practicing euthanasia 🙂

Database Connection Pooling in Java With HikariCP

When we are discussing about Database connection pooling, most of my colleagues are relying on the good old Tomcat dbcp. However there is a niche, really funny and interesting, the guys that a competing for the best DBCP. And HikariCP is clearly a step ahead of everyone.

The article Database Connection Pooling in Java With HikariCP is presenting how to use a custom DBCP in your software.

Hikari Performance

Hikari Performance

I think it would have been great to present the differences with the standard DBCP and further debate on the advantages/disadvantages of the solutions. A good idea for a newt article 🙂

Concurrency: Java Futures and Kotlin Coroutines

Java Futures and Kotlin Coroutines An interesting article about how Java Futures and Kotlin co-routines can coexists. Honestly I am a little bit disappointed and thought that Kotlin would make things easier like in Node.JS

Are Code Rules Meant to Be Broken?

Another article about Code Quality and we could be dubious whether exists an answer to that question : Are Code Rules Meant to Be Broken.

I won’t enter too much in the details, the author’s point of view seems to be Code Rules are good if they are respected. If they are broken, it implies that the Code rules need to evolve 🙂 What do you think about it ?

Java vs. Kotlin: First Impressions Using Kotlin for a Commercial Android Project

This article is interesting since it presents a feedback session on using Kotlin in a Android project.

The following big PLUS to use Kotlin are :

  • Null safety through nullable and non-nullable types, safe calls, and safe casts.
  • Extension functions.
  • Higher-order functions / lambda expressions.
  • Data classes.
  • Immutability.
  • Coroutines (added on Kotlin 1.1).
  • Type aliases (added on Kotlin 1.1).

  Quality Code Is Loosely Coupled

Quality Code Is Loosely Coupled

This article is explaining one of the most dangerous side of coding : Coupling. Must to read article despite the lack of schemas.

Five Habits That Help Code Quality

This article is a great introduction on code assessment. These five habits are indeed things to track in your software code as a sign of decay and code sickness.

The habits are : – Write (Useful) Unit Tests – Keep Coupling to a Minimum – Be Mindful of the Principle of Least Astonishment – Minimize Cyclomatic Complexity – Get Names Right

10 Good Excuses for Not Reusing Enterprise Code

This article is really useful in the context of Digital Transformation to assess which softwares you should keep and throw.

Example of excuses : – I didn’t know that code existed. – I don’t know what that code does. – I don’t know how to use that code. – That code is not packaged in a reusable manner.

Test proven design

An interesting article and example on how to improve your own code using different skills. I really recommend to read this article and the next future ones : Test proven design.

1

Codacy : an easy-to use code quality review solution

Codacw tendancy analysis

Some time ago, I organized a talk on “Code Quality and why developers should care about” for my company. In that presentation, I demonstrate some tools, unfamiliar for the audience : young developers and battle-hardened IT developers.

One among these tools has brought to me a lot of questions : Codacy. I will present its features and perform a comparison between Codacy and SonarQube from SonarSource.

Continue Reading