from Hacker News

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

by krishadi on 2/12/25, 12:09 PM with 12 comments

• by dakiol on 2/12/25, 2:34 PM

  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.

• by matt_s on 2/12/25, 2:00 PM

  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.

• by carlos-menezes on 2/12/25, 1:34 PM

  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.

• by philomath_mn on 2/12/25, 4:18 PM

  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.