4 ms·
Ask HN: What is your failed “big rewrite” horror story?
Inspired by: https://news.ycombinator.com/item?id=27932036
Curious what your failed big rewrite[1] horror stories are? You know, when someone bravely declares they can and should rewrite a project from scratch, but it doesn’t end well?
1 - https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
- gregjor 5y agoAll of them -- I've never seen it work. I've had a customer for ten years. Their web site works, gets used a lot, but the UI is dated/clunky and there's some functionality (integrations with other systems) the customer would like to implement. They've never been able to get enough internal consensus to change anything significant. Then the board hired an outside firm to rewrite the whole thing from scratch. I don't bid on new development projects as a rule and in this case I knew the customer would not have clear and complete requirements (from long experience with them). So I offered to help the outside firm, but they only contacted me for some logins and otherwise did their own thing. $60,000 and 8 months later the new site got staged, missing major functionality and showing the most hideous font I've ever seen -- not readable at all, and a gray-on-black color scheme only a designer fresh out of art school could love. They had not staged intermediate versions for review. No version control, almost nothing worked. My customer asked me to intervene to salvage something but the outside firm held the code for ransom, demanding even more money. So that ended in a lawsuit and to this day my client still has their original clunky but working web site up. $60K is small potatoes compared to the clusterf*k rewrites at the IRS, California DMV, etc. But for a small-ish non-profit that's a whole year of IT support/programming down the drain. A couple of people lost their jobs over it. I worked at a big logistics/shipping company about 20 years ago. They had a huge internal project (60+ people) supposedly rewriting an Oracle/ColdFusion based app (only a small part of it was web-facing) in Java. That went on for a couple of years, with almost nothing to show for it, before management scrapped the whole thing. I worked at a Federal agency for a while supposedly as part of a big rewrite project triggered by Y2K worries (1960s-era Fortran/COBOL code no one understood anymore). It was all meetings, not a single line of code got written for the "new system." Eventually they pulled the plug. Y2K came and went and the ancient code continued working.
- massung 5y agoI's mostly agree with this. But I'd note for the OP that "complete rewrites" are not necessarily guaranteed failures. It depends how it's done and what the goals of the rewrite happen to be. The two types of rewrites I've seen be successful: 1. Ship of Theseus rewrites. This is where small modules/segments of code in the project are completely rewritten and integrated back into the whole. This has the advantage of being able to test the new code against existing data constantly, get user feedback, etc. Over time, the entire project has been rewritten, but the benefits (for the cost) have been proven at every step. And you get repeated buy-in from everyone involved from management down to end-users. 2. Massive change of requirements. One may argue (successfully) that this may not actually count as a rewrite as opposed to just being considered a new project. These are usually successful when the project being replaced is notoriously bad/complained about by end-users. But, the same concerns still exist: no benefits are seen until done, potential loss of functionality, new bugs, lost knowledge (read: edge cases not ported), etc. Ship of Theseus rewrites are successful quiet often. The others... yeah, not so much. It's rare. But, it can happen.
- gregjor 5y agoThe OP asked for horror stories. I didn’t mean to imply rewrites can’t work, only that I’ve never seen it work (in 40 years programming). My very first programming job at Nike was what was then called a “conversion,” moving a working code base from one platform (PDP-11) to another (DECSystem 20). Conversions were common rewrite-type projects back then (‘70s) because every vendor and computer model had a unique OS and set of languages and tools. That project succeeded. Throughout the project the project manager (one of the best I’ve worked with) resisted every attempt to expand scope so we could focus on getting the current functionality working on the DEC 20. It was partly automated and then required line-by-line examination of the source code and rigorous unit testing. I wouldn’t call it a ground-up rewrite, no new features got added and we had a working system to start with. It was more like an evolution. I worked on other conversions early in my career and they mostly got derailed when management and users took the opportunity to “enhance” what was working as part of the straight conversion, and/or when the programmers were allowed to get carried away adding functionality themselves.
- busymom0 5y agoAbout 4 years ago, I was working on a sudoku app with good design. I built it in few months and was close to completion. But then I had the "genius" idea to make the app multiplayer - where a couple or more could fill a sudoku puzzle together and whoever filled the cells with more advanced techniques required and more cells would win. I didn't just stop there. I wanted to make the puzzles even more complex for multiplayers where instead of a 9x9 Grid, you could have larger grids. I started working on it and it soon got quite complex. I wasn't just building the sudoku app itself, I was adding an extra layer of networking and syncing of the puzzle board on top plus puzzles which weren't traditional 9x9. Eventually it got so complicated that I gave up. Basically a few months of work where I had built a pretty good designed traditional sudoku app and close to 90% competition had ended up being too complicated for my skills when I tried to add too many bells and whistles to it. I basically had a 90% completed app, then a whole bunch of junk which I don't think many people were even interested in playing. But I hadn't stopped to think about whether anyone was even interested in it. Anyway, about 6 months later, when my parents asked me what happened to the sudoku app I was working on, I finally reopened the code. I literally deleted everything I had added on top of the simple traditional sudoku app. Removed the networking logic, removed the larger grids, got rid of all the junk. Then I worked on the remaining 10% and finished it to put it on the App Store. I learnt my lesson to not add useless bells and whistles to projects and to always stop and rethink whether what I am doing actually has a market or not.
- h2odragon 5y agoEarly DOS days: Knew a guy whose job was re-implementing a fairly simple database system that was in a goofy COBOL based thing, with a 64kb maximum database size. He'd been brought in with a brand new copy of dBase 3 to modernize the membership DB. AFAIK when they finally got their copy of dBase 4, the "new system" had not ever been shown to a user. Their member list came out of 12 different instances of the old app, and de-duplicating and merging to make it into useable, mailable labels was the job I got called in for. Utterly horrible. They'd have done better with a spreadsheet.