- a bunch of Jira tickets get assigned to be worked on the next sprint. The vast majority of them are product features, and a tiny bit are about tech debt and known bugs (if any)
- depending on the team, you may allocate 15%-20% of the team's capacity for unexpected/new bugs in the next sprint if they do impact the business
> I'm curious about how a software developer's time is distributed across different phases of a product's lifecycle, how much time is spent writing code, reading code, writing design docs during each of these phases.
There's no such a distinction. I don't distinguish the time I spent between writing code and reading code, writing design docs vs reviewing them. There are no "phases", everything is mixed up (some call that an iterative process) in the sprint. You may have Jira tickets tagged with "brainstorm" or "spike", used to "think about the requirements of a specific product ticket", but they could be as well be part of the jira ticket designated to that specific product feature. This distinction is mainly used by your engineering manager, but for engineers is just a silly distinction.
Feature development doesn't usually slow down in favor of bug fixes. Rarely, if the bug is big enough and impact a big client, then 1 or 2 team members are allocated to it, but the rest of the team keeps pushing features.
This is my experience in a typical mature "cool" (in their own view) startup. They pay top notch, but they also ask for the moon. Not FAANG, though.
At big companies you may have something like a cash cow and it is on maintenance only type of efforts. No major product enhancements being done but more internal work and maintenance like database indexes, disk space, server upgrades, etc. There might be other teams building new products/features based on your systems and data so there are internal integrations needed. Then whenever some CIO comes along that was sold a bill of goods on an ERP system you have to go thru those transitions.
At a SaaS company now and it feels like product development is where the majority of the focus is, to the detriment of maintenance. For example being a few versions behind the latest security patch level while someone is making promises at a conference on things that aren't even built yet.
In my experience, the longer an application has been running and in service, the less time developers are spending writing fresh new code or even prototyping, etc. I think this is where that "itch" comes in for developers to invent new things. I totally understand that, its fun to build a new application.
I could imagine that the cash cow part of a product gets all the attention in the beginning. Does that stay the same through the life cycle? Or do you see that it takes a back seat while feature development on top of that takes the center stage at alter stages of the product?
[edited to add this] I also see that it's sometimes easier to build something new, than to go on maintaining something.
It really depends on a bunch of factors: the environment, company structure, your role — you get the gist.
Early on, most time goes into writing new code, with some design docs if the team is structured — this is as simple as writing a README.md or having a static documentation website.
Once you have users, writing new features slows down, and more time shifts to bug fixes, refactoring, and keeping things running. In startups, this transition happens later since growth takes priority. I haven't worked for any large companies yet but I assume they tend to balance maintenance earlier.
Just curious to know if you see the following trend:
As a codebase matures, the amount of time spent of code maintenance increases and with bug fixes, it gets harder to spot them and the amount of code that is required to solve them is little.
Yes. We have at least one team dedicated to identifying bugs and maintaining technical quality. For example they statistically analyze our CI runs to identify regressions. They find some subtle bugs that would be difficult to identify through one's own experience.
This is a team that no one interested in their career progression should ever be on. This is usually a dead end and almost impossible to spin in behavioral interviews.
Well, not my experience at all and combining that with the link I posted, I suspect you are mistaking what I am referring to. What are you basing your statement on?
Let’s say I am interviewing two people with the same technical skills.
One says that they have spent the last couple of years fixing bugs and analyzing the CI builds. The other talks about leading major new initiatives or being responsible for a major new feature and I dig into it. Guess which one I’m going to hire?
In the terms of promo docs, which shows more “impact”, “scope” and “dealing with ambiguity”?
It sounds like you would hire the one building CRUD apps. Perhaps I was unclear in my original post, technical quality teams don’t analyze CI and fix bugs. The team in my org builds sophisticated tools to analyze CI runs and teams self service the bug fixes. When you are operating at large scale and delivering products, there is no limit to impact or scope; ambiguity is inherent.
There are some ebbs and flows, but usually everything is happening all at once. There is usually never a single product, and even then different parts of a product will be in different stages at the same time.
So you could be doing heavy prototyping or feature work on a mature product if you are enhancing it in some way, or you could be doing some maintenance / refactoring / bug-fixes on an early stage product.
The distribution of time between those tasks will change over the life of the product, but there is rarely a "feature complete" stage in my experience.
Typically, it's Friday and it's sprint planning:
- a bunch of Jira tickets get assigned to be worked on the next sprint. The vast majority of them are product features, and a tiny bit are about tech debt and known bugs (if any)
- depending on the team, you may allocate 15%-20% of the team's capacity for unexpected/new bugs in the next sprint if they do impact the business
> I'm curious about how a software developer's time is distributed across different phases of a product's lifecycle, how much time is spent writing code, reading code, writing design docs during each of these phases.
There's no such a distinction. I don't distinguish the time I spent between writing code and reading code, writing design docs vs reviewing them. There are no "phases", everything is mixed up (some call that an iterative process) in the sprint. You may have Jira tickets tagged with "brainstorm" or "spike", used to "think about the requirements of a specific product ticket", but they could be as well be part of the jira ticket designated to that specific product feature. This distinction is mainly used by your engineering manager, but for engineers is just a silly distinction.
Feature development doesn't usually slow down in favor of bug fixes. Rarely, if the bug is big enough and impact a big client, then 1 or 2 team members are allocated to it, but the rest of the team keeps pushing features.
This is my experience in a typical mature "cool" (in their own view) startup. They pay top notch, but they also ask for the moon. Not FAANG, though.
At big companies you may have something like a cash cow and it is on maintenance only type of efforts. No major product enhancements being done but more internal work and maintenance like database indexes, disk space, server upgrades, etc. There might be other teams building new products/features based on your systems and data so there are internal integrations needed. Then whenever some CIO comes along that was sold a bill of goods on an ERP system you have to go thru those transitions.
At a SaaS company now and it feels like product development is where the majority of the focus is, to the detriment of maintenance. For example being a few versions behind the latest security patch level while someone is making promises at a conference on things that aren't even built yet.
In my experience, the longer an application has been running and in service, the less time developers are spending writing fresh new code or even prototyping, etc. I think this is where that "itch" comes in for developers to invent new things. I totally understand that, its fun to build a new application.
I could imagine that the cash cow part of a product gets all the attention in the beginning. Does that stay the same through the life cycle? Or do you see that it takes a back seat while feature development on top of that takes the center stage at alter stages of the product?
[edited to add this] I also see that it's sometimes easier to build something new, than to go on maintaining something.
It really depends on a bunch of factors: the environment, company structure, your role — you get the gist.
Early on, most time goes into writing new code, with some design docs if the team is structured — this is as simple as writing a README.md or having a static documentation website.
Once you have users, writing new features slows down, and more time shifts to bug fixes, refactoring, and keeping things running. In startups, this transition happens later since growth takes priority. I haven't worked for any large companies yet but I assume they tend to balance maintenance earlier.
Just curious to know if you see the following trend:
As a codebase matures, the amount of time spent of code maintenance increases and with bug fixes, it gets harder to spot them and the amount of code that is required to solve them is little.
Yes. We have at least one team dedicated to identifying bugs and maintaining technical quality. For example they statistically analyze our CI runs to identify regressions. They find some subtle bugs that would be difficult to identify through one's own experience.
https://lethain.com/managing-technical-quality/ discusses when it makes sense to build such a team.
This is a team that no one interested in their career progression should ever be on. This is usually a dead end and almost impossible to spin in behavioral interviews.
Well, not my experience at all and combining that with the link I posted, I suspect you are mistaking what I am referring to. What are you basing your statement on?
Let’s say I am interviewing two people with the same technical skills.
One says that they have spent the last couple of years fixing bugs and analyzing the CI builds. The other talks about leading major new initiatives or being responsible for a major new feature and I dig into it. Guess which one I’m going to hire?
In the terms of promo docs, which shows more “impact”, “scope” and “dealing with ambiguity”?
https://www.levels.fyi/blog/swe-level-framework.html
It sounds like you would hire the one building CRUD apps. Perhaps I was unclear in my original post, technical quality teams don’t analyze CI and fix bugs. The team in my org builds sophisticated tools to analyze CI runs and teams self service the bug fixes. When you are operating at large scale and delivering products, there is no limit to impact or scope; ambiguity is inherent.
That’s fair. Isn’t that more of a DevOps/SRE team then and a completely separate career track for most people than software development?
There are some ebbs and flows, but usually everything is happening all at once. There is usually never a single product, and even then different parts of a product will be in different stages at the same time.
So you could be doing heavy prototyping or feature work on a mature product if you are enhancing it in some way, or you could be doing some maintenance / refactoring / bug-fixes on an early stage product.
The distribution of time between those tasks will change over the life of the product, but there is rarely a "feature complete" stage in my experience.