What I mean is if I am breaking a programming project estimate down into tasks as much as possible would there be a good maximum to make the tasks. Meaning if I say the max is 4-6 then if any task is more hours than that it needs to be broken down into more tasks. I feel like there is a point where this becomes not much more useful though and think that a max of 10-12 hours is acceptable, the boss does not agree. The idea here is to be able to know as well as possible how much time is needed to complete the task but at the same time I think there is a point where too much breakdown is meaningless until you actually dive into the code. Any thoughts or common practice?
Make the breakdown structure detailed enough to allow you make a proper estimation, but not too detailed so you'll have trouble maintaining and tracking it later, when things change (not if things change, but when things change).
It doesn't really matter the number of hours a task in WBS is estimated.