The rework was driven by a desire to move an existing web application to mobile. That was fair enough, I suppose. Given the market they were trying to go after I think that was a reasonable choice. But alongside that it was decided by the powers that be that the entire backend, which was already well abstracted from the frontend and would have transitioned to mobile quite nicely, would be replaced by Firebase to speed up development for the team of junior frontend-focused developers it hired to build the project. That choice was far more dubious, but the leaders were convinced it would speed up development and allow them to hire cheaper workers.
The initial prototype of the rewrite was stood up impressively quickly. However, the weight of the technical debt accumulated during that time saw further development start to crawl to a snail's pace. For example, every little new data access pattern that came up revealed that the database (Firestore) wasn't structured effectively for the use case requiring a lot of work in constantly massaging the data. The automated test suite found in the original was also foregone in the rewrite, which multiplied the manual effort required to verify every change. And there was, simply, a much higher defect rate. Months upon months were spent just fixing bugs.
Long story short, new leadership wanted to focus on mobile and thought they could do it faster and cheaper switching to tech that low-cost developers would be capable of using. One reasonable, in my opinion, choice followed by a whole lot of bad choices. Perhaps that falls under political/ego reasons, but I'm not so sure. The intent was sound, but the execution fell flat.
They're rebuilding it from scratch. The documentation needed to build a system from scratch should be provided entirely by management, product managers and product owners.
Should developers write some documentation? Sure. But "how to rewrite this shit from scratch" is not the kind of documentation developers should be writing.
Talented people do exist. And untalented developers are more common than talented ones. There's no reason to doubt OP or to call him a shitty documentation writer just so it matches your world view.
- I was not ever told to write documentation, never given time to do it, and was working around 100 hour weeks, almost all spent coding, under tight deadlines.
- I'm a senior developer / Architect with 25+ years experience and a degree in Computer Engineering from a top school
- The 19 people who replaced me were almost all right out of coding camps with 1-3 years experience
Each of those 19 developers could have been just as good, but the problem/requirement was likely very different for them.
The 19 people were all right out of coding camps and each had 1-3 years experience.
The reason there was 19 developers is probably because someone pulled the number 19 out of their ass.
The rewrite was warranted because so much stuff (API, UI) was changing entirely due to external forces. What it actually did (from the user's perspective) was pretty similar, how it did everything needed to be different. I didn't write it myself again because I was busy with other stuff.
There were numerous reasons it failed (we can say failed because the customer ended up going elsewhere). Devs were inexperienced, overconfident, chose inappropriate technology for the problem and wouldn't listen to advice. There was nobody in a tech lead position on the project (CTO at the time constantly spouted nonsense about "self organising teams") so everybody spent their time shaving their pet yaks and hoping other people would handle the difficult/boring bits. Deadlines were repeatedly issued but had no bearing on reality so everyone knew they'd be missed - thus they were meaningless.
Then after this transpired, it was up to the team to make all the APIs available to this new pretty-much-finished app and for it to be wired and polished into a "production ready" app. This process, along with all the unfinished, badly written, tech-debt ridden crap, took a year. Barely months in, simple features by this wunder-dev took weeks, incessant complaints about tech-debt by said dev, endless meetings and hand-wavy excuses about how "no we can't do it that way, it's not the angular way, and you don't know JS so shush!".
Countless angular upgrades and package updates with breaking changes, renderer this, web-component that, cordova that, do we support react, oh we didn't make it mobile friendly cause we can use native component libraries, oh crap we have multiple repos zomg now we need Lerna to compile our app, what about events let's use an event bus on the FE, and on and on, with no end in sight. It's years later and it's still being supported as if it's the holy grail, all while it continues dragging down actual feature dev. All this for a couple-dozen screens.
If the company had a more long term mindset, they would have been allocating something like 3x devs continuously the whole time, so that when the original dev quit, there was no crisis.
But… they didn’t. I’ve seen this kind of short term thinking up close plenty of times. Nothing to do with documentation quality.
Why, in any scenario, would something well coded and documented need that amount of rework otherwise? Aside political, ego reasons that is...