6 ms·

Unpopular view here ... if it took 19 engineers to rebuild your software - that seems like a failure on your part (not theirs).

jraph 4y ago
Can you develop? It seems to me the need to rewrite the project at all, depending on the reasons, could be the failure, not that it took one year and 19 engineers to do it.
- fendy3002 4y ago
  Yes, we're lacking context here. Most of the time developers will want to build things from scratch given the opportunity. It's simply easier (from one's opinion) and the time gap may provide with better tooling and frameworks. That applies whether the new lead developer is good or bad. And longer time is not a good indicator too, since previously op may cutting corners to make development faster. However 19 engineers handling one project that can be handled by one person previously is imo, a sign of not optimized work. That is, granted if the scope of work is the same for both.
  - heretogetout 4y ago
    IME it's a sign of one developer doing their best to get a system up and running well enough for business to get by (basically a MVP) and business not providing the staff necessary to improve upon it until it is too late. Maybe it needed 19 engineers all along. At least, that has been my experience in the past.
izzydata 4y ago
I don't think there is enough context to determine that. It seems plausible that it could maybe be a mix of being highly productive due to the lack of overhead of working with many other people and some obfuscation through complexity probably for the same reason that he wasn't working with other people and could optimize for only his own legibility.
- gsibble 4y ago
  It was a combination of being the sole decision maker, architect, product manager, etc. without having to coordinate with a team, being very senior (25+ years), being a very fast coder (I produced 4x the lines of code of anyone else at the company during my year there), and the fact they only hired jrs other than me straight out of coding camps. They expected code monkeys to write Shakespeare. This was a bank with extreme security requirements that I build in a high sophisticated microservice architecture. My code was easy to read, but the systems were certainly not easy to understand, especially to jrs with zero experience in microservices, Kubernetes, devops at all, etc..
- kayodelycaon 4y ago
  There are a lot of explanations possible. I’ve deal with with the aftermath of with “80% developers” my entire career. In two weeks, they’d write a good enough program with no handling of edge cases or errors. Replacing one of these with a proper application can take a year. I’ve also dealt with a team of programmers who couldn’t come close to my productivity solo. It was due to constraints and communication overhead, not incompetence. When you go from a solo dev to a team of 19, that sounds more like a change in strategy by management than anything else.
  - bmitc 4y ago
    I’m not sure what you mean by 80% developers, but I am generally cautious on developers who are seen as uber productive. I worked with one in the past, and they would blow through so much code. It amazed everyone else, but they left a literal wake in the code. It was just a gigantic mess when you dove into it that wasted so much time down the road in onboarding others, refactoring it, maintaining it, etc.
    - deleted 4y ago
      [deleted]
    - kayodelycaon 4y ago
      Sorry, I should have clarified, they are developers that quickly do 80% of the work and move to the next thing. They are often quite intelligent and very productive, but aren't inclined to think a problem through to completion.
deleted 4y ago
[deleted]
fartsucker69 4y ago
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...
wgj 4y ago
Junior/mid devs will rewrite something they don't understand, rather than analyze and understand it. Everyone wants a green field project.

jraph 4y ago

Can you develop? It seems to me the need to rewrite the project at all, depending on the reasons, could be the failure, not that it took one year and 19 engineers to do it.

fendy3002 4y ago
Yes, we're lacking context here. Most of the time developers will want to build things from scratch given the opportunity. It's simply easier (from one's opinion) and the time gap may provide with better tooling and frameworks. That applies whether the new lead developer is good or bad. And longer time is not a good indicator too, since previously op may cutting corners to make development faster. However 19 engineers handling one project that can be handled by one person previously is imo, a sign of not optimized work. That is, granted if the scope of work is the same for both.
- heretogetout 4y ago
  IME it's a sign of one developer doing their best to get a system up and running well enough for business to get by (basically a MVP) and business not providing the staff necessary to improve upon it until it is too late. Maybe it needed 19 engineers all along. At least, that has been my experience in the past.

izzydata 4y ago

I don't think there is enough context to determine that. It seems plausible that it could maybe be a mix of being highly productive due to the lack of overhead of working with many other people and some obfuscation through complexity probably for the same reason that he wasn't working with other people and could optimize for only his own legibility.

gsibble 4y ago
It was a combination of being the sole decision maker, architect, product manager, etc. without having to coordinate with a team, being very senior (25+ years), being a very fast coder (I produced 4x the lines of code of anyone else at the company during my year there), and the fact they only hired jrs other than me straight out of coding camps. They expected code monkeys to write Shakespeare. This was a bank with extreme security requirements that I build in a high sophisticated microservice architecture. My code was easy to read, but the systems were certainly not easy to understand, especially to jrs with zero experience in microservices, Kubernetes, devops at all, etc..
kayodelycaon 4y ago
There are a lot of explanations possible. I’ve deal with with the aftermath of with “80% developers” my entire career. In two weeks, they’d write a good enough program with no handling of edge cases or errors. Replacing one of these with a proper application can take a year. I’ve also dealt with a team of programmers who couldn’t come close to my productivity solo. It was due to constraints and communication overhead, not incompetence. When you go from a solo dev to a team of 19, that sounds more like a change in strategy by management than anything else.
- bmitc 4y ago
  I’m not sure what you mean by 80% developers, but I am generally cautious on developers who are seen as uber productive. I worked with one in the past, and they would blow through so much code. It amazed everyone else, but they left a literal wake in the code. It was just a gigantic mess when you dove into it that wasted so much time down the road in onboarding others, refactoring it, maintaining it, etc.
  - deleted 4y ago
    [deleted]
  - kayodelycaon 4y ago
    Sorry, I should have clarified, they are developers that quickly do 80% of the work and move to the next thing. They are often quite intelligent and very productive, but aren't inclined to think a problem through to completion.

deleted 4y ago

[deleted]

fartsucker69 4y ago

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...

wgj 4y ago

Junior/mid devs will rewrite something they don't understand, rather than analyze and understand it. Everyone wants a green field project.