3 ms·

> writing the initial code for a feature is about 25% of the total work involved for that feature. Over a decade ago, I had a job where we were juggling severa

> writing the initial code for a feature is about 25% of the total work involved for that feature. Over a decade ago, I had a job where we were juggling several projects and needed to track our work in 15 minute intervals. The timesheets were mildly annoying but they did allow us to determine that number empirically. We came up with an average ~20%. Remarkably little variation across projects too. The implications to estimation should be obvious - any software planning process that resembles a feature factory and only estimates 20% of the work is systematically neglecting the remaining 80% - things like fixing bugs, performance optimization, backup drills, dealing with dependencies, code review, CI/CD/Release process, QA testing, docs, UX testing, training, technical communication, etc. Multiplying the initial estimate by 5x is not just some cheeky heuristic to pad estimates, it's damn near proven by empirical evidence IMO. Constantly shoving more and more features into software systems without doing any of the engineering work to support it leads to bad outcomes. Who could have guessed /s

perrygeo 2y ago
The only factor that explained the variation was the success of the project. More successful projects spent less time writing initial code relative to time in maintenance. Failed projects spent a great portion on writing code. Again, the obvious implication is that if your project is a failure, you sink less time into maintaining it. The only way to reduce the maintenance burden is to not have users. There is some not-so-subtle self-sabotage going on here. It's difficult to figure out causality in these cases. Did the project fail because of inadequate investment in engineering foundations? Or did we deprioritize work on it because we knew it wasn't going to take off? Likely both, working in a negative feedback loop.
- cpeterso 2y ago
  > Failed projects spent a great portion on writing code. Perhaps because the project requirements were not known or kept changing? I'm reminded of the quip about "Why spend an hour in a meeting when you can spend weeks writing code to avoid it?"
  - perrygeo 2y ago
    In this case it was simply that successful projects got used, thus more bugs and maintenance issues were uncovered. It's super easy to run a web service if it doesn't have any users :-)

perrygeo 2y ago

The only factor that explained the variation was the success of the project. More successful projects spent less time writing initial code relative to time in maintenance. Failed projects spent a great portion on writing code. Again, the obvious implication is that if your project is a failure, you sink less time into maintaining it. The only way to reduce the maintenance burden is to not have users. There is some not-so-subtle self-sabotage going on here. It's difficult to figure out causality in these cases. Did the project fail because of inadequate investment in engineering foundations? Or did we deprioritize work on it because we knew it wasn't going to take off? Likely both, working in a negative feedback loop.

cpeterso 2y ago
> Failed projects spent a great portion on writing code. Perhaps because the project requirements were not known or kept changing? I'm reminded of the quip about "Why spend an hour in a meeting when you can spend weeks writing code to avoid it?"
- perrygeo 2y ago
  In this case it was simply that successful projects got used, thus more bugs and maintenance issues were uncovered. It's super easy to run a web service if it doesn't have any users :-)