This article has been written as “basic knowledge” for Junior Java developers to help them tracking their bugs in Java software.
Java In Production : some useful tools for profiling and diagnostic.
Tools
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
These tables illustrate the difficulty to lead to a successful project.
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
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
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.
Which framework to generate source code ?
I have been recently writings tools to convert Beanshell code in Java. This is a technical post to compare some frameworks to generate java source code.
About me
You are on this site because we are sharing the same passion : Software
My name is Sylvain Leroy and I am software programmern, startup funder. My speciality is to save software from all kind of sickness.
About Me in Switzerland 🙂
What is defining me the most precisely is my passion for Software and coding.
As explained on my company site (byoskill.com), I have three passions :
- Software craftmanship (SQA)
- Legacy software migration
- and startup environments
I have been doing that from so long
I discovered coding something around 10, on our family Commodore 64/128.
Commode 64/128
Back in these times, I didn’t know about coding, I learnt how to use it to get what I wanted. Games, interests. I was curious to manipulate and understand this strange creature.
Basic program
Of course I had normal activities, friends, sports. However this machine fascinated me. We had two big books, in English, a foreign language to me, full of code listing. I spent numerous to painstakingly type them on this computer. Some code were games, some revealed to be funny noise / sound effects, plane engine.
I had the chance to be from the generation who grew up with computers and incredible progresses. We switched one day to x86, a 286 with single coloured screen. I remember the screen was pale glowing in my room at night. I made obvious progresses in Basic, QBasic, Visual Basic (my college passion), switched to Pascal(Delphi) at 14 during the middle school. At 16, I was efficient in Delphi and I tried the C language without enthusiasm.
I discovered at the same time ASM/Z80 programming to use on my Texas calculator and I switched from Pascal to ASM, with all the set, TASM, TLINK.
The book “the Art of Assembly Language” had a huge impact on me. I printed it with our good old printer in 4 big binders. And started to love it.
I continued until 18 my experience of assembly programming on two fields :
- virus programming
- software cracking using SoftICE, C/C++ decompiler and some tools I could find on the dark net at that time. Internet was so slow…
I finally has switched to C/C++ late 19 using Visual C++. I have been slowly mastering it. I was always tempted to switch to ASM using asm statements. To program with limited resources is so much funnier than with high level languages.
A lucky meeting changed my life and course
I have been following a Computer science diploma in two years at the University of Rennes 1 (Lannion). And then I discovered I could not work in industrial automation because a wrong choice of course. I switched to a general computer sciences Licence (3rd year).
During my master degree, I choose as exam project, a technical project in which we were supposed to write a Java syntactic analysis tool (linter). This meeting with this professor, Francois Bodin, had a influence of my final year of study, and at minimum the next ten years of my life.
Together, under his tutelage, we imagined a research project, a project of company creation, and we launched it. It was Tocea, which lived from 2009 to 2015 before being absorbed by a Software Editor, Metrixware. In my mind; I am and will be eternally grateful, for the opportunity – the seed – Francois offered to me. It has been an incredible adventure. This environment was totally new for me, my family, my surrounding, given our social origins.
Serenitec : research project
Tocea : my passion, and my initiatory route
Offically Tocea has been created in March 2010 after 3 years of research project and one year of incubation.
Research project Serenitec
We were three at the beginning, and the project was called Navis.
Against, there, Marie-Anne and Florent, have been of a great help and influenced positively the view of what could be Tocea, both socially and professionally.
Tocea / modele_carte_recto2
A french article here of this period.
Francois Morin, is also important to me, since we brought Tocea to its maturity together. Co-founding a company is never simple. We had to learn from each other, to be able to work together. The stability and the trust of our relationship has been like the warm fireplace that attracts the frozen voyagers. And we simply attract the best to reach together our ambitions as a small software editor we were.
Our company had his life , successes and failures , joy and pain but I remember it as a wonderful social experience. I have seen students coming for their first experience, getting their first job, growing up and becoming our real assets. Tocea has been a success (humanely) thanks our people. They gave us our trust, and we tried together to create something great.
Links :
- http://www.images-et-reseaux.com/fr/blogs/2012/12/tocea-une-jeune-pousse-qui-voit-grand
- https://www.inria.fr/centre/rennes/actualites/tocea-leve-300k-euros-de-fonds
- http://www.techinfrance.fr/membre/tocea
The transition
Tocea ended peacefully to become a more serious business under the acquisition by Metrixware. Fair enough, Metrixware, a well-known software editor specialized in Legacy system and migrations, saved us at that time, our business was in a full transition after some critical mistakes and a hard business year (for the whole sector).
I learnt much from being there about processes, change management and also company culture. Three things crucial for the success of any projects.
Now in Switzerland
I am enjoying my new road, currently in Switzerland. I have been discovering this great country and particular job environment since the begin of 2017.
I have been since working full time as IT Consultant for large institutions. Recently, I created a small structure www.byoskill.com in which I am providing my experience for dedicated missions.
Each encounter, with either a Software Developer either a team, is pushing me forward to what I love the most :
Empowering people, saving Software and developing great tools.
How to do a legacy software migration : a successful checklist
Here is a small checklist about how to migrate a legacy migration and to ensure its success.
This article is part of my work to explain my knowledge about Software migration in the company Byoskill.
How to make a software developer happy ?
To be or not to be (happy), that’s the question. In this article, I expose some thoughts about what could make a software developer happy in his work. I wrote this article with several targeted audience in mind : Junior developers, Senior Techleads and H&R resources.
Developing with S3 and Java : useful links
This article is part of my web research to prepare the development of a new feature using Amazon S3 Webservices.
Java developer testing toolbox
An article dealing with Java application and testing frameworks and related libraries. Continue Reading
TOP open-source dashboard solutions 2017
A Dashboard can be a very efficient communication tool for a team, between managers and business units. It enables an organization around a vision to share common goals. It can also be useful to identify weaknesses in processes and adapt your strategy according to them.
Test and Data Generation for Java Unit tests
Today I was preparing a presentation about Software Code quality for a TechTalk on Thursday. I made a search on Internet about Automatic Unit test generator and Data Generators. I will present some tools I have tried. Today, we will speak of Randoop.
Randoom Test Generator
The first tool name is Randoop.. This tool is existing since 2007 and its purpose is to generate automatically unit tests 🙂 Directly from your class definition!
To use it you have two choices:
- You can use your software JAR or classpath directory.
- You can include it in your test compile path (on gradle or maven) and creates a main or unit test.
To explain short the theory, thanks to the Java reflection it’s quite easy to produce automatic tests validating some contracts of your API.
Some examples: – toString() should never returns null or throws an Exception – equals() and compareTo() methods have a long list of constraints – Reflexivity: o.equals(o) == true – Symmetry: o1.equals(o2) == o2.equals(o1) – Transitivity: o1.equals(o2) && o2.equals(o3) ⇒ o1.equals(o3) – Equals to null: o.equals(null) == false – It does not throw an exception
Therefore this tool is generating unit tests with JUnit(TestSuite) for the list of classes you provide.
I have done some tests and you can reach 50-60% of coverage quite easily.
The main drawbacks of the solution are: – The unit tests are drawing a snapshot (precise picture) of your code and its behaviour however some tests are really non-sense and you don’t want to edit them. – They don’t replace handwritten tests since the tool is not understand the different between a String parameter emailand fullName. He will mostly use dumb strings.
About the technology, it’s not production ready: – I had troubles with the jar and its dependency plume. – The JAR is a fatjar and coming with dependencies that broke my software.
In conclusion, I will fork the software and try to fix the problems to make it more popular 🙂