4 ms·

can you explain? there's no logical link here for me at all. if OP was never born and they had to build that app from scratch, and it took them 1 year and 19 e

can you explain? there's no logical link here for me at all. if OP was never born and they had to build that app from scratch, and it took them 1 year and 19 engineers to do it, you wouldn't be posting the same thing.

headsoup 4y ago
To me there is no logical reason for needing 19 engineers other than poor documentation, written in a niche language (or non-standard for the org) or they use a consulting firm that of course said it will take 19 engineers and needs rebuilding. Why, in any scenario, would something well coded and documented need that amount of rework otherwise? Aside political, ego reasons that is...
- gsibble 4y ago
  They never gave me time to write documentation. I was working 100 hour weeks, almost all coding, under tight deadlines. You can see why I wanted a raise.
- tartoran 4y ago
  Op was not saying it was good and documented code so a lot of context is missing here but even if it was a POC that needed a more generic/maintainable code rewrite, it would still justify keeping the original developer who wrote the code and giving them a market value compensation. Now again, we’re missing context here and it is not impossible that the code was a complicated mess that the original dev cobbled together culminating in a hot fire and they were too arrogant to be kept around. I’ve seen variations of that scenario. However, incompetency of the management is more likely to be the cause. Let’s keep in mind that in a lot of companies they management want to make sure all devs are replaceable so they don’t obtain too much leverage.
  - headsoup 4y ago
    Exactly, that was my point. It's not that the engineer simply coded better than 19 other people together could, it's that other factors came into play. If the intent was to portray they are just a 19x developer... I know I'd have some questions...
- sanitycheck 4y ago
  I've been there, a client-side app I built in 6 months got a rewrite which took 5 people 2 years and ended up with about half the original functionality. 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.
- PeterisP 4y ago
  If they simply pretended it does not exist, they should be able to rewrite it with 1 developer in less than a year. If they can't and need an order of magnitude more resources, that's a sign of incompetence on the new team.
  - gsibble 4y ago
    They were all code monkeys right out of coding camps.
- randomdata 4y ago
  I watched something similar play out once upon a time, albeit not quite to the scale of 19 developers, but rather six developers. I expect a team of 19 would have found a similar fate. 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.
- ratww 4y ago
  > To me there is no logical reason for needing 19 engineers other than poor documentation 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.
  - gsibble 4y ago
    Thank you. The biggest issues were: - 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
  - headsoup 4y ago
    I'm not saying the developer is crap, I'm saying it didn't take 19 developers to do what he/she did. Each of those 19 developers could have been just as good, but the problem/requirement was likely very different for them.
    - gsibble 4y ago
      I have 25+ years experience and a computer engineering degree from a top university. The 19 people were all right out of coding camps and each had 1-3 years experience.
    - ratww 4y ago
      Are the requirements really 19 times harder though? Or at least N times larger, so that it requires 19 times more people? I most sincerely doubt it. The reason there was 19 developers is probably because someone pulled the number 19 out of their ass.
- zo1 4y ago
  Witnessed a bit of the inverse or similar, dunno. Something written over many years and working very well, was to be "rewritten" as a web site/app/mobile thing. And a "single" (wunder) dev pulled a miracle with a great POC demo where seemingly all needed functionality was almost there and working, all in a week which included many late nights according to them. This person had used the magical power of "angular" and all these "fancy" new things that wow-ed the leadership, that was so used to that "slow thick client" with it's outdated "C# compiled code". 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.
- bluesnowmonkey 4y ago
  To me it rings true. 1x is how much the company could get away with paying, so they did, because companies are reluctant to part with money. 19x is closer to how much value the system was providing, and thus how much resources were allocated to replacing it when that suddenly seemed necessary. 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.
notahacker 4y ago
Logically if the OP was never born, his software wouldn't exist, and a company wouldn't have made the judgement that replacing his software asap would be a good use of up to 19 man years of budget (Of course it's also unknown whether that decision was a sensible one, whether it was forced by external pressure like API changes despite the stability and maintainability of the original system and whether the OP's software possessed equivalent functionality to its expensive replacement. All we know is the choice to create the software again from scratch was, to some extent, influenced by what had already been created)

headsoup 4y ago

To me there is no logical reason for needing 19 engineers other than poor documentation, written in a niche language (or non-standard for the org) or they use a consulting firm that of course said it will take 19 engineers and needs rebuilding. Why, in any scenario, would something well coded and documented need that amount of rework otherwise? Aside political, ego reasons that is...

gsibble 4y ago
They never gave me time to write documentation. I was working 100 hour weeks, almost all coding, under tight deadlines. You can see why I wanted a raise.
tartoran 4y ago
Op was not saying it was good and documented code so a lot of context is missing here but even if it was a POC that needed a more generic/maintainable code rewrite, it would still justify keeping the original developer who wrote the code and giving them a market value compensation. Now again, we’re missing context here and it is not impossible that the code was a complicated mess that the original dev cobbled together culminating in a hot fire and they were too arrogant to be kept around. I’ve seen variations of that scenario. However, incompetency of the management is more likely to be the cause. Let’s keep in mind that in a lot of companies they management want to make sure all devs are replaceable so they don’t obtain too much leverage.
- headsoup 4y ago
  Exactly, that was my point. It's not that the engineer simply coded better than 19 other people together could, it's that other factors came into play. If the intent was to portray they are just a 19x developer... I know I'd have some questions...
sanitycheck 4y ago
I've been there, a client-side app I built in 6 months got a rewrite which took 5 people 2 years and ended up with about half the original functionality. 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.
PeterisP 4y ago
If they simply pretended it does not exist, they should be able to rewrite it with 1 developer in less than a year. If they can't and need an order of magnitude more resources, that's a sign of incompetence on the new team.
- gsibble 4y ago
  They were all code monkeys right out of coding camps.
randomdata 4y ago
I watched something similar play out once upon a time, albeit not quite to the scale of 19 developers, but rather six developers. I expect a team of 19 would have found a similar fate. 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.
ratww 4y ago
> To me there is no logical reason for needing 19 engineers other than poor documentation 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.
- gsibble 4y ago
  Thank you. The biggest issues were: - 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
- headsoup 4y ago
  I'm not saying the developer is crap, I'm saying it didn't take 19 developers to do what he/she did. Each of those 19 developers could have been just as good, but the problem/requirement was likely very different for them.
  - gsibble 4y ago
    I have 25+ years experience and a computer engineering degree from a top university. The 19 people were all right out of coding camps and each had 1-3 years experience.
  - ratww 4y ago
    Are the requirements really 19 times harder though? Or at least N times larger, so that it requires 19 times more people? I most sincerely doubt it. The reason there was 19 developers is probably because someone pulled the number 19 out of their ass.
zo1 4y ago
Witnessed a bit of the inverse or similar, dunno. Something written over many years and working very well, was to be "rewritten" as a web site/app/mobile thing. And a "single" (wunder) dev pulled a miracle with a great POC demo where seemingly all needed functionality was almost there and working, all in a week which included many late nights according to them. This person had used the magical power of "angular" and all these "fancy" new things that wow-ed the leadership, that was so used to that "slow thick client" with it's outdated "C# compiled code". 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.
bluesnowmonkey 4y ago
To me it rings true. 1x is how much the company could get away with paying, so they did, because companies are reluctant to part with money. 19x is closer to how much value the system was providing, and thus how much resources were allocated to replacing it when that suddenly seemed necessary. 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.

notahacker 4y ago

Logically if the OP was never born, his software wouldn't exist, and a company wouldn't have made the judgement that replacing his software asap would be a good use of up to 19 man years of budget (Of course it's also unknown whether that decision was a sensible one, whether it was forced by external pressure like API changes despite the stability and maintainability of the original system and whether the OP's software possessed equivalent functionality to its expensive replacement. All we know is the choice to create the software again from scratch was, to some extent, influenced by what had already been created)