What successful conversion/rewrite of software hav

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 10 months ago.

Improve this question

What successful conversion/rewrite have you done of software you were involved with? What where the languages and framework involved in the process? How large was the software in question? Finally what is the top one or two thing you learned from being involved with the process.

This is related to this question

Answer 1

Converted the main company app from pre-standard C++ to standard C++. We had a multimillion dollar sale contingent on making it work on AIX, and after looking at it we decided that converting to standard C++ was going to be just as easy as converting to IBM's traditional C++.

I don't know the line count, but the source code ran to hundreds of megabytes.

We used standard Unix tools to do this, including vi and the assorted compilers.

It took a few months. Most of the fixes were simple ones, caught by the compiler and almost mechanically fixed. Some of them were much more complicated.

I think my main takeaway was: Don't get too awfully clever with code in a language that hasn't been standardized yet, or is likely to have things change in unexpected ways. We had to do a lot of digging in some of the ingenious adaptations/abuses of C++ streams.

Answer 2

Migrating the B-2 Stealth Bomber mission software from JOVIAL to C. 100% fully automated conversion. Seriously!

Main lesson: using configurable automated conversion tools is a huge win.

See DMS Software Reengineering Toolkit.

Answer 3

I'm going for "most abstruse" here:

• Ported an 8080 simulator written in FORTRAN 77 from a DECSystem-10 running TOPS-10 to an IBM 4381 mainframe running VM/CMS.

Answer 4

I rewrote 20,000 lines of Perl to use "use strict" in every file. I had to add "my" everywhere it was needed and I had to fix the bugs that were uncovered during the process.

The biggest thing I learned from doing this is, "It always takes longer than you think."

I had to get it done all at once overnight so that the other coders would not be writing new, unfixed code at the same time. I thought it would go quickly, but it didn't, and I was still hacking on it at 6 AM the next morning.

I did get it complete and checked in before everyone else started work though!

Answer 5

Re-wrote a system for a company that processes legal invoices - the original system was a VB monstrosity that had no idea of good OO principles - everything was mixed together. The HTML did SQL, and the SQL wrote HTML. A large part of it was a custom rules engine that used something like XML for the rules.

Two teams did the re-write, which took about 9 months. One team did the web front end and the backend workflow, while the other team (that I was on) re-wrote the rules engine. The new system was written in C#, and was done test-first. Adding new rules to the system when we were done was dirt simple, and it was all testable. Along the way we did things like convert the company from VSS to SVN, implement continuous integration, automate the deployment, and teach the other developers how to do TDD and other Scrum/XP practices.

Managing expectations was crucial through the project. Having a customer that was savvy about software was very helpful.

Having a mix of large scale (end-to-end) tests along with comprehensive unit and integration tests helped tons.

Answer 6

I rewrote a large java web application to an ASP.Net application for a realty company for various reasons.

The biggest thing I learned is that, no matter how trivial the feature the original system had, if it's not in the second system, the client thinks the rewrite is a failure. Expectation management is everything when writing the new system.

This is the biggest reason rewrites are so hard: it seems so easy to the client ("Just re-do what I already have and add a few things.").