Hacker News Reader

Comment by bpizzi | Hacker News Reader

We're (team of 2) rewriting an old enterprise ERP system made of ~1M of C89 non-portable loc, tens of thousands of handwritten PLSQL loc, thousands of business rules carefully abstracted in sql data, tens of complex screen designed and scripted on a no-name RAD software that was the current fad back in the days, and some companion pieces in VB6 because, you known, 'C89, not anybody can do it'.

That's fun.

The new system is a quiet simple SOA arch with a dull, only-real data db layer, backend in Go with code-generation, frontend in es6 migrating to elm.

That looks the IT guys have when we say 'no really, we don't need IIS or Java', its priceless :)

The interesting part actually lies in handling both product management and sales for the new version while handling the day-to-day coding part.

Sometimes I think I should write a book on those subjects :)

View on HN

I'm also in the planning stages of re-writing ~1M lines of C doing hardware control for a telecoms system. It's going to be replaced with Elixir (basically Erlang) because it's the perfect fit (which is unsurprising given its a telecom system).

My prediction is that it will be 10-20k lines of code when I'm done because there's so much obsolete cruft to remove. Plus ~1k of C as a shim layer to allow an incremental transition.

Nice, glad to know there's other brave souls that choose the Big Rewrite path, despite the latent idea in our industry that every one of those projects are meant to fail.

My approach is that there are a few things that the default answer for should be "no" and then you have to justify (maybe just to yourself) why they're appropriate in this case. Macro Fu in C, template meta-programming in C++ and rewriting from scratch are all examples of these.

In this case I am avoiding the 'throw it all away and start from scratch' approach. It would be infeasible for the intervening period. I am putting together an approach that would get us there in a year or so, but we can lop off smaller chunks to rewrite (the existing architecture is a series of daemons, which helps us there).

Personally what's interesting for me is:

1. (Assuming you're an outside contractor) How much do you charge?

2. How do you do estimates on this project? Or do you just do it bit by bit?

3. Are you switching over part by part or will deploy in a period?

If you can, you should at least write a blog post. A book will be amazing though!

I'm a simple employee with some management duties, it's small company (20p), I estimate my wage to be on the low end of the local market (french, not in the capital), but the position is quiet unusual so it's difficult to compare.

At the beginning there was only vague goals, not estimates, now 4y later I can tell how much days a functionality will take within a 30% margin error. But it's only based on personal appreciation, tightly coupled to having personally designed the new arch from the start.

The migration strategy that I chose was to hijack the sales activity and pick which new projects should go on the new version. That way we can stay away from replacing years of specific functionalities for picky customers until we have a good idea of how much the business module is ready for prime-time.

I should definitely write a book, there's so much to say - maybe in 2020! :)

Definitely quite a unique position compared to the common rewrite story. Small company, long-term rewrite timeline, small rewrite team, able to influence the sales activity and deployment. I think these constraints are important to your success (and fun factor), but I don't have the complete picture. I'm really welcome to any points against what I wrote above; currently I'm intrigued on reading on how software projects works or doesn't work in real life and your story is really interesting.

That sounds super interesting. You should absolutely write a book...or, if not that, a blog. I'd read it.

/me gathering momentum...

Reply on news.ycombinator.com