zlacker

The problem is you most likely introduced new bugs, created new build/test toolchains, and your team knew the previous codebase, probably quite well.

I have never in my professional career seen a solo developer rewrite something from scratch successfully in isolation. It almost always turns into the developer leaving, either because they became burnt out being the sole SME, or it fluffed their resume enough for them to find a new job. Everyone else on the team is left holding the bag.

I'm actually more surprised your manager/PM let you do this. Most of the time this happens as a skunkworks thing.

Rewrites should always be incremental, never big bang, and never in isolation.

>>candid+(OP)
I agree with all of your comment. This was indeed pretty unique case. No one in my small company (including me) actually knew that codebase, it was total mess written by original EE (who sayed himself he was not a programmer), it was pretty small (32kb of rom puts a limit on your codebase) by "team of programmers" standards and currently we have no one else who could actually do anything with that code, one coworker is learning to write firmware and new version is already much more readable and reasonable. It was TOTALLY in need of rewrite, but not all code is a good candidate for something like this.

> I'm actually more surprised your manager/PM let you do this. Most of the time this happens as a skunkworks thing.

I didn't know it will take so long, delving into this was like a frctal of bad code. When I've tried to fix something, it required fixes in other places which required fixes in another places. I could make several TDWTF posts from that code.

> Rewrites should always be incremental, never big bang, and never in isolation.

Yeah, but that codebase was not that big, so it was medium size bang. Never in isolation - there was no one other at my company who could actually do it and it was tested functionally by others once it was stable enough.

>>candid+(OP)
I saw this scenario happen. Startup, one person wrote an insanely complex engine that did a lot of stuff; allowed them to scale up, get funding, etc. But... it became a complexity nightmare. The answer was... hire a new single expert, and let them rebuild a bunch of stuff, and... there were now 2 insanely complex layers, one of which sort of knew how to interact with the other one. The first person had gone, and the second person ... just didn't come in the office much (2-3x/month), and... was 'above' all the 'day to day' needs.

First phase was about 4 years. Second phase started, and I was there in year 2 of that. 6 month contract on my part. Took me months just to figure everything out.

Background - the core engine was PHP. The 'rewrite' was also PHP.

I left, and got some updates from a few folks later. They hired some python and JS people ("we can't find/hire any PHP people!"). And... they gave the python and JS people greenfield "rebuild chunks of this system". And months later, this was all spun as "PHP sucks, node rocks". Because.. well... look what was getting done. They couldn't hire many PHP folks because... they weren't paying terribly well compared to the level of skill required to deal with the core engine.

This was far less about tech as it was management. Giving a team of JS people who are all colocated, have a working system to inspect and emulate, can choose their own tools, and are given a long time frame... it's not all that surprising they had some success compared to "let one guy go off on his own and don't talk to him for weeks at a time".

Looking back, the second guy was trying to recreate much of the flexibility of the first system, but in a 'modern' way, which was very much not a great idea (the complexity and flexibility were the core problems, from what I could tell). The node and python teams avoided implementing much of the flexibility, and they could get away with it a bit more because by that time the business was more established, and had a better understanding of what they needed and what was not.

Part of how I viewed it was "it took 12 people 8 months to recreate 20% of what one person did in PHP in a couple of years". But that's certainly putting an overly pro-PHP spin on it. ;). By all means, though, having just one person be the sole person who knows 90% of the system, with no time given to train others... huge red flag. Took me a few months to suss out just how precarious that was, and I understand the business need to spread out the risk. Was just very annoyed that the "rebuild" decision was spun as "php sucks" instead of "solo-expert-working-in-isolation" sucks.