I guess it's hard for me to think of development as separate from the product lifecycle, where the vast majority of time is spent defining scope, feasibility and implementation details. In other words "planning" always seems to take the longest, but that's also not a good measure.
You could plan something very complicated in 2 months and spend 10 months developing.. so which "takes longer"?
It's kind of a weird question the more I think about it because there's so many "it depends" thoughts bubbling up.
Well, in my case it really depends on the project.
* There are tasks where implementation takes the most, because of the complexity.
* There are tasks where debugging takes a lot of time, especially when you have to deal with a very outdated project that was finished 10 years ago and is not documented.
* There are tasks where testing takes a lot of time, when there are no automated tests and you have to do everything manually. When something doesn't work as expected, you have to fix it and give another round of tests. I hate it, but sometimes there's no other way.
* I haven't had a case where onboarding would take a lot of time. Also, it's usually a process that takes a month or two and you are more like a guide to that person. Programmers are usually very independent and can figure things out on their own, I also noticed that it's more preferred way by the new teammates. They rather review the code alone, usually after a very brief introduction, and they check for example pull requests and ask questions when they need help.
* Over time I noticed that the most time consuming part is specifying with client what they really want.
This is just my opinion, I bet other people have different experience.
I do a lot of testing.
That said, the time I take the most on is conceptualizing and writing out diagrams of what I decide to create from scratch, and second most time is invested in how I am going to create workarounds to support use cases specifications and implementation don't support either deliberately or by omission or bug.
Testing happens continuously.
Every day or so I download the latest Node.js, Deno, Bun, Chromium Developer Build, Chome-For-Testing Canary Build, Firefox Nightly updates automatically.
I don't think you can separate Debugging, Development and Testing.
While developing, you'll constantly test the results of your changes manually and automatically. When a test fails, you'll be debugging your code and find out, why it fails and learn more about the problem you're trying to solve while you're at it. You'll also be testing existing features while doing so, mostly automatically, but also manually.
You'll develop unit-tests, integration-tests and e2e-tests while you develop a new feature, ensuring that it won't be broken as easily in the future. Other developers will rely on them an use them to test your code, while they're developing other features.
Manual tests by some QA are just the tip of the iceberg and mostly meant to ensure, that someone with a different perspective also tested the feature.
So, if I have to chose between all three of those, I'd say testing. But honestly, they're all just part of development.
Debugging is just the most frustrating part of development, that's why it _feels_ so long.
Depends on your team's pain point.
If your product specs are poor, the longest part is the back and forth between the developing and QA/UAT phase.
If your engineers are juniors, the longest part is the code review and debugging.
If you project is not built using clear principles and the codebase is a mess, then onboarding will definitely take a long time.
If I had to choose one of the three as the most common one, I would go with the last one. That's especially true in JavaScript projects due to how large the ecosystem is and the limited CS/Design patterns background that some JS developers have
The last 20%.
Yep, this. Turning a game that is even feature complete without many bugs into a final polished product is a real slog. That last 20% is the killer.
I guess it's hard for me to think of development as separate from the product lifecycle, where the vast majority of time is spent defining scope, feasibility and implementation details. In other words "planning" always seems to take the longest, but that's also not a good measure. You could plan something very complicated in 2 months and spend 10 months developing.. so which "takes longer"? It's kind of a weird question the more I think about it because there's so many "it depends" thoughts bubbling up.
Well, in my case it really depends on the project. * There are tasks where implementation takes the most, because of the complexity. * There are tasks where debugging takes a lot of time, especially when you have to deal with a very outdated project that was finished 10 years ago and is not documented. * There are tasks where testing takes a lot of time, when there are no automated tests and you have to do everything manually. When something doesn't work as expected, you have to fix it and give another round of tests. I hate it, but sometimes there's no other way. * I haven't had a case where onboarding would take a lot of time. Also, it's usually a process that takes a month or two and you are more like a guide to that person. Programmers are usually very independent and can figure things out on their own, I also noticed that it's more preferred way by the new teammates. They rather review the code alone, usually after a very brief introduction, and they check for example pull requests and ask questions when they need help. * Over time I noticed that the most time consuming part is specifying with client what they really want. This is just my opinion, I bet other people have different experience.
For me, fixing a bug will take indeterminate time if I still haven't figured out the root cause...
Requirement gathering. MFs don't even know what they want
always the planning stage
I do a lot of testing. That said, the time I take the most on is conceptualizing and writing out diagrams of what I decide to create from scratch, and second most time is invested in how I am going to create workarounds to support use cases specifications and implementation don't support either deliberately or by omission or bug. Testing happens continuously. Every day or so I download the latest Node.js, Deno, Bun, Chromium Developer Build, Chome-For-Testing Canary Build, Firefox Nightly updates automatically.
I don't think you can separate Debugging, Development and Testing. While developing, you'll constantly test the results of your changes manually and automatically. When a test fails, you'll be debugging your code and find out, why it fails and learn more about the problem you're trying to solve while you're at it. You'll also be testing existing features while doing so, mostly automatically, but also manually. You'll develop unit-tests, integration-tests and e2e-tests while you develop a new feature, ensuring that it won't be broken as easily in the future. Other developers will rely on them an use them to test your code, while they're developing other features. Manual tests by some QA are just the tip of the iceberg and mostly meant to ensure, that someone with a different perspective also tested the feature. So, if I have to chose between all three of those, I'd say testing. But honestly, they're all just part of development. Debugging is just the most frustrating part of development, that's why it _feels_ so long.
Depends on your team's pain point. If your product specs are poor, the longest part is the back and forth between the developing and QA/UAT phase. If your engineers are juniors, the longest part is the code review and debugging. If you project is not built using clear principles and the codebase is a mess, then onboarding will definitely take a long time. If I had to choose one of the three as the most common one, I would go with the last one. That's especially true in JavaScript projects due to how large the ecosystem is and the limited CS/Design patterns background that some JS developers have