[gtsteve]

This doesn't really sound like a big-bang rewrite as such but an incremental development process. The sort of rewrite that would be a major strategic mistake is where you start with a new repository and begin re-implementing the entire product, but this seems all perfectly sensible to me.

This just sounds like the sort of incremental Ship of Theseus [0] development that many of us are doing. The product I'm working on has had enough key internal portions rewritten over a long enough time (including interestingly the job management system) that you could say it's a rewrite compared to the product from 2 years ago.

[0] https://en.wikipedia.org/wiki/Ship_of_Theseus

[barking]

I'd like to see some idea of what they mean by big. An order of magnitude in terms of lines of code and the number of engineers they had for the job and how long it all took versus how long the original took to write etc. One of the things that scares me about something like this are all the seemingly illogical bits of code that were added over time and are actually that way for a reason because they fix some edge case or whatever. Hard to see those not getting swept away in a rewrite as well as a whole bunch of new rarely occurring issues added. A complete rewrite strikes me as something that's almost guaranteed to be buggier than what it replaces, at least for awhile.

[mgkimsal]

> A complete rewrite strikes me as something that's almost guaranteed to be buggy

Likely buggy, but buggy in different ways. The real test will be in measuring the number and quality and severity of bugs, as well as the ability to identify and repair them in both systems. A testable system with good test code written may still be 'buggy', but will help foster a sense of confidence when making the fixes required.

[LandR]

>I'd like to see some idea of what they mean by big. An order of magnitude in terms of lines of code and the number of engineers they had for the job and how long it all took versus how long the original took to write etc.

Yeah, at my last place before I left, they were looking to do a rewrite of their main project that had been the result of years of hundreds of developers working on it. The time-scale was wooly, but was expected to be between 5 and 10 years and probably require ~200 developers and testers.

This was rewriting millions of lines of code, very little would be reusable.

I don't know if they went ahead with it or not, but it was looking like it would descend into chaos.

[eej71]

What prompted everyone to want to rewrite so much code?

[LandR]

They were on a system where if bugs existed past a certain date of them being logged, their was financial penalties that had to be paid.

Also adding new features was incredibly slow, painful and dangerous. Even a minor change resulted in so much manual regression needing to be done. It was absurd.

[baud147258]

The company where I work is doing (and is close to finishing) a big rewrite of one the product. The base version is deployed on-prem at our clients, the new one will be cloud service, with the same features. But the on-prem version is still worked on and supported (I'm working on it) alongside the cloud one, the cloud one is to offer a less cumbersome alternative.

[barking]

Is the on-prem one Windows based? Also by less cumbersome do you mean the cloud one has fewer features or is just easier to get up and running with it because it's a browser based. Are the company expecting your on-prem one to fade away over time etc? Could you give any information of what each was written in and an order of magnitude, hundres of thousands of loc etc. Sorry for all the questions but I'm nosey! No problem if you can't.

[baud147258]

The on-prem is windows-based, we're delivering new version as msi. The goal of the cloud version is be easier to get up and running, since there's no installation steps and (I guess) less configuration to do. The company might want the on-prem to fade, but it won't happen in the short term since we still have clients. The on-prem is 15-20 years old, but not always actively worked on and with ~1M Loc (including sql scripts, setup, config files, but not the test suite). The cloud project started last year and I think there's already clients using it, but I don't have access to the code, so I have no idea for the loc.

[barking]

Thanks for the info. I am involved with a Windows based product and we've thought now and again about doing something like this. We have a competitor that is browser and cloud based but the product seems to be a lot less featured. It feels like they are quite limited in what locally connected hardware (cameras, modems, card readers, barcode readers, printers and scanners) they can interact as well as seamless bridges to other locally installed software. With desktop software this is fairly straightforward but I don't know if this is/was a problem for cloud software.

[baud147258]

I'm afraid I wasn't clear, it's installed on Windows server and user access it via Internet Explorer (because of ActiveX, in theory we'll do the switch for Chrome soon). To interact with card readers, cameras and printers, we're using a bunch of extension, including a java applet (!) that we'll have to migrate.