I do think there is something unique to software that is different to pure engineering disciplines and it’s not completely down to power dynamics, which exist everywhere. I suspect it’s that software is really a design process rather than a pure engineering one, with input and creativity needed at every step - it’s a process of discovery, not just execution of a task.
Even in trivial cases, it may appear something is a one-word change / five minute job so you say it’ll be done today. But somebody just asked you to attend a meeting this afternoon that has just filled out your schedule for the day, and you have to conduct an interview tomorrow that’ll drain your energy for the rest of the day, so you’ll have start it next week. Or maybe you’ll try to squeeze it in now (and drop the context of what you were already doing to the detriment of that task) because it should a be quick fix.
But once you start to do it, you notice that this needs to go through the localisation system. That’s not going to fit the UI anymore in Indonesian, we’ll need to modify the UI component too… It also breaks an old integration test snapshot, how do you update those again? Looks like nobody’s touched that for a year… etc. etc.
The specifics are not important but I’m trying to demonstrate that for complex systems, even a simple change is difficult to predict with so many unknowns.
Maybe it does only take 5 minutes, that great. But if there is more to it than expected, I think discovering that and identifying that this involves tech debt then adjusting workload accordingly is best. I don’t think that initially planning that the task is going to take 5 minutes (or an hour, or half a day) is any better than simply stating the task exists among others, then checking on the status later. Assigning time slots feels like it’s a distraction that gives the illusion of predictability and encourages unrealistic planning.
