Ask HN: How do software devs spend time across a product's life cycle?

5 points by krishadi 1 year ago | 12 comments

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.

And, for 'each of these phases' I mean during ideation, prototyping, and after gaining users shifting towards maintenance, refactoring, and scaling.

At what point does feature development slow down in favor of bug fixes, tech debt reduction, and performance improvements?

Also, how does time allocation change in different environments—startups vs. big companies, SaaS vs. consumer apps, open-source vs. enterprise software?

Any patterns you've noticed?

dakiol 1 year ago |

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.

mattbrewsbytes 1 year ago |

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.

krishadi 1 year ago | |

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.

carlos-menezes 1 year ago |

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.

krishadi 1 year ago | |

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.

ruraljuror 1 year ago | | |

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.

philomath_mn 1 year ago |

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.